‘Forty five percent (45%!) of project costs industry-wide is rework’

That’s the claim that Jamal Moustafaev makes in “Who Needs Walkthroughs, Inspections and Peer Reviews?”.

That is a sobering statistic, but it only tells part of the story.  When you remember that a $1 mistake early on in the project easily balloons into a $40 fix later on, you begin to see why it is so important to do requirements correctly.  However, even good requirements have flaws.  Therefore, it is vital to pull together your team and do a thorough walk-thru of the requirements, project plan and statement of work.  It is important that these documents undergo a peer review by a fellow project manager as well as the technical project team.

Moustafaev makes several good points about pitfalls and things to look for in walk-thrus and reveiws.  A worthwhile read!

Technorati Tags: it pm,project management,information technology,requirements gathering,statement of work,project charter,project plan,scope,walkthroughs,walkthrus,walk-throughs,walk-thrus,inspections,reviews

Should It Be Hard?

From the “Don’t Make It Hard” files: The right way and the wrong way to make things hard.

We should clarify the phrase “don’t make it hard”.  Some things are meant to be hard.  It is a tool.  It is used  to better our own (personal or corporate) positions.  For example, you want it to be hard for your competitor.  You want to create what Seth Godin calls “The Dip” for those who would otherwise take your market share.  You want it to be hard enough for candidates who apply for a job that the bottom feeders are weeded out.

May I use an analogy?  Cement is a good all purpose agent to build structures.  Cement, or concrete if you prefer, makes excellent sidewalks and driveways under the proper conditions (I’ll spare the long story about my own driveway).  However, it can also make a horrendous mess if poured incorrectly.  It also isn’t good for using a chisel on in order to chisel out a statue, similar to marble.

Both cement and marble are hard.  However, they have different purposes.

There is a small company looking for staff, but they have had a vacant position for some time now.  That may be hard to believe in this economy.  It isn’t because of cost necessarily.  They are just looking for a good quality fit.

Are they being too picky?  Maybe.  Maybe not.  Time will tell.  Most likely, they will find that quality person and fill the spot.

Barriers to entrance is one way that making it hard can be good.  You want the best for your investment, after all.

Of course, that type of barrier depends upon knowing what you want.  One way you can make things hard is to have an “Ambiguous Scope”.  A common cause of an ambiguous scope is the client doesn’t know what they want.

Contrast the example of the small company above with another company looking for a contractor to fill a need for a short-term task.  Initially, it seems they know what they want.  The funny part is that it should be a rather straight-forward little project.  Emotions and politics have clouded their judgment.  They will probably pay too much for too little because what they are asking for doesn’t match their real concerns.  As you dig into it, you begin to realize that the contract may not be in your best interest to pursue.  Red flags are being thrown, flares are going off, and your gut tells you it’s not a good idea.

In other words, you begin to realize that they are making it hard – on themselves.  Without going into specifics, they cannot see the forest for the trees, so they are lost in the forest even though there is a pathway in sight.

There is a time to make it hard – for your competitor, for prospective long-term relationships (yes, there are hopefully barriers to entry for marriage as well as employment) and even for criminals.  However, when you make it hard for yourself, those in a long-term relationship with you (which presumably includes employers) or customers, then you are adding unneeded stress to everyone around you and potentially harming those relationships.

Technorati Tags: it pm,information technology,project management,making things hard,obstacles,barriers to entry,contracting,employment,interviews

Avoiding Project Failure: Gathering Requirements

After a round of LinkedIn discussions about project failure, it was a general consensus that most project failures stem from bad or vague requirements.  This is a recurring theme in project management, it seems.  Well, in “Eight Things Your Business Analysts Need to Know”, it appears that Brad Egeland would agree:

In an online poll of 2,000 business professionals, the question was asked, “What are the key challenges in translating user needs into system specifications for mission critical projects?” 50% stated poor requirements definition as the key challenge. Inadequate risk management (17%), poor scope control (15%), and communication problems (14%) followed far behind as key challenges.

After the discussion online, someone posed the question to me, “Who should gather the requirements?”  Again, Egeland’s article answers the question, “What about the business analysts?  What role do they play?”

Egeland’s article, which distills down a whitepaper from Gantthead, goes on to identify 8 competency areas for BAs.

But, you know, input from a BA is usually not hard to get on a decent-sized project.  On smaller projects, though, it can be difficult to even get a BA assigned.  So, now what?  Well, it usually falls to the project manager if a project falls under a certain number of hours.  Therefore, it would behoove any decent PM to check out these competency areas as well, especially the first 5.  Don’t be afraid to pull in an architect or a SME to answer questions, either.

If you really want to rescue a project from the safety of victory and dash it into the jaws of defeat, though, then ignore competency #6 “End-User Support”.  How many projects have I seen that were “done” but lived on as the walking dead that sucked the life out of team members long after it was put away?

Technorati Tags: it,it pm,project management,information technology,requirements gathering,competencies,business analysis

Use Cases and User Stories – Just Degrees of Difference?

What is the difference between doing use cases and doing user stories?  Use cases are UML methods of bridging user requirements with a system.  User stories are an Agile way of doing the same thing.  However, throw into the mix that there are formal and informal use cases as well as a use case brief, and you have a potentially confusing situation.

What are the differences between these, then?  Well, Scott Sehlhorst at the Tyner Blain blog tries to tackle this question.  Perhaps they are really just different points on a continuum of overhead and detail.  Throw in the level of reader trust, and you can graph these different items.  “User Stories and Use Cases” is an interesting read.

Technorati Tags: pm,it pm,project management,requirements gathering,use cases,user stories,agile