Get Your Gliffy On

As mentioned in Robert Scoble’s “Office in a Cloud” article, here is a tremendous database of useful online applications put together by Ismael Ghalimi, creatior fo the Office 2.0 Conference:

   http://o20db.com/db/setup 

You’re bound to find something useful and/or fun in here. Have you seen Gliffy yet? It’s like an online version of Visio. How about the custom forms available at Wufoo? These are not entertainment sites (although I admit to smiling while using them). They are full-blown applications for creating (and, more importantly, sharing) drawings and custom forms.

Click here for my sample Gliffy diagram. Thanks again to Fast Company editors for providing useful information for hard-working small business owners.

BA and PM – different views of Scope

Tina Joseph of B2T Training illustrates that, while the Project Manager and Business Analyst roles overlap, they have very distinctly different objectives and focus… requiring different skills and training:

The PM delivers a project charter which defines the project, the objectives, and a list of project participants including resources. The BA delivers a project scope which defines the boundaries of what is going to be analyzed as part of the project including high-level processes and a more detailed analysis of the root cause of the problem being addressed.  Overall, the roles have a different function. The PM is ultimately responsible for the project completion, its budget, resources, and a timely completion. The BA is responsible for fully understanding the business problem and providing complete analysis to ensure that the solution best meets the needs of the business. These roles have completely different focuses requiring unique training for each role.

Have you ever driven a nail with a crescent wrench? I have. What a noisy mess that is! Use the correct resource for the business analysis job… read Tina’s full post here.

Identifying user roles is critical

The Botswana government spent an extra $1.52M (USD) to cope with a user base that more than doubled during their implementation. See the story here.

We are to assume that they simply underestimated the number of people to be served but this does not jive with the “scope creep” comments later in the story.

Rather than a jump in the number of users — which would be a scalability problem — a more likely reason for the huge increase in scope is that they did not account for each kind of user. They failed to interview the target audience carefully enough to discover each unique role (job function) that would be involved.

After grasping the basic business problem at hand, defining the roles to be served by an application is the next most important task during requirements gathering. Each role, by virtue of having a different kind of work to do, will have different objectives and therefore different requirements for the application. Until an application designer knows Who they are serving, they will have an underdeveloped view of What the application must do.

The diagram below shows one way to think of systems analysis and a thorough requirements gathering process. The proper analysis path is Goals -> Roles -> Scope. We call this the “pyramid of confidence” because each new discovery builds on something more important.

ConfidencePyramid.jpg