Random Acts of IT Project Management

Project Management for Information Technology

Posts Tagged ‘requirements gathering’

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

Posted by iammarchhare on 25 August 2009

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!

Posted in Requirements | Tagged: , , , , , , , , , , , , , | Comments Off on ‘Forty five percent (45%!) of project costs industry-wide is rework’

Highlights From Seth’s Blog

Posted by iammarchhare on 20 August 2009

Most of you know by now that I enjoy Seth Godin’s blog.  You’d be amazed how many of his posts relate to project management as well.  Here are some highlights from this month:

1. “All storms are perfect” makes the point that a perfect storm can be anticipated.  I don’t want to give his whole post away (it’s very short), but notice where the actual failure is in his example.  Now, ask yourself, “What sort of ongoing verification have I put into place once this project has been completed?”

2. Godin tackles a requirements definition problem in “Are we solving the same problem?”  If you’ve ever had to sit through some large vendor’s sales pitch, you surely can relate to this post.  How many sales people drone on and on about features you aren’t even interested in?  Worse, have you ever delivered a project only for the enduser to say, “That’s not what I wanted”?  Perhaps you were, like the vendor sales person, focusing on the solution and not the problem.

3. Godin’s article on “When tactics drown out strategy” reminds me of my own difficulty in separating tactics and strategy.  It is far too easy for me to focus in on details and forget why I’m trying to get it done in the first place.

4. In “Critics that matter”, Godin points out that there are critics that matter, critics that are loud and critics that are difficult.  I have alluded to this in previous posts that you won’t please everyone.  As I have stated in “Ambiguous Scope”, the sponsor needs to define for you when a project is “done”.  It needs to be measurable.

However, there will be other key stakeholders on the project that you need to identify and engage them in shaping requirements.  They are called “stakeholders”, but don’t kid yourself that all of them have a stake in “the project”.  Don’t lose sight of the fact that their real concern is in the product being produced!

You know the audience is somewhat different, the tools are different and even the emphasis is different, but there are a lot more similarities between marketing and project management than either side will admit!

Posted in PM Basics | Tagged: , , , , , , , | Comments Off on Highlights From Seth’s Blog

Avoiding Project Failure: Gathering Requirements

Posted by iammarchhare on 28 May 2009

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?

Posted in Requirements | Tagged: , , , , , , | 2 Comments »

Use Cases and User Stories – Just Degrees of Difference?

Posted by iammarchhare on 26 May 2009

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.

Posted in Agile, Requirements | Tagged: , , , , , , | 1 Comment »

Ambiguous Scope

Posted by iammarchhare on 11 May 2009

If you don’t know where you are going, then you won’t know when you arrive.  It really is a simple concept, but it seems to go over the heads of many executives.  Unfortunately, it seems to go over the heads of some IT folks as well.  When that executive wants something and wants it now, it is hard to push back sometimes.  However, “something” is not a scope statement!

If I am dying of thirst, and I ask for a drink, then should I be dissatisfied when I get a cup of coffee instead of water?  Now, I love a good cup of coffee as much as the next coffee addict, but I also know it isn’t going to cure my thirst.  No, I should have been more specific.  The person giving me the drink should’ve asked questions.  Both failed to ask questions, and the task was not a success.

What makes a successful project?  Isn’t it one that delivers the goods?  If you don’t know what the goods are, how do you know when you succeed?  You don’t.  How do you know when you fail?  When you have angry people making demands of you, which is almost a surety if you don’t live up to their expectations.  That is almost a surety when the scope is not properly defined.

Ask the questions on any project:

  1. What is success?
  2. How do you measure success?
  3. When are you done?
  4. How do you measure done?
  5. What is the minimum required?
  6. What is the maximum timeframe?
  7. Can the minimum required reasonably be planned, constructed, tested, reworked and retested in the maximum timeframe?
  8. Will subject matter experts (SMEs) be available throughout the timeframe, or will you have to rely upon less experienced workers?a. Who is indispensible to the project’s success?  When will they most be needed and can you be guaranteed their availability during critical times?

    b. If less experienced people will be used, then is it reasonable that you can still do the minimum within the maximum timeframe?

  9. Are there any stakeholders who do not buy-in on the changes?
  10. Do you have executive support (real, not lip service)?

If any of the above are a concern, and if you cannot come up with a reasonable workaround or mitigation action for it, then it needs to be identified as a risk factor.  The likelihood of the risk occurring must be widely published.  The project sponsor must be engaged with the risk.

Remember that an unmeasurable business goal is no goal at all.  Don’t start out with a hardware or software change as the goal.  No, hardware and software changes may be functional requirements that support the business goal, but they are not in themselves the goal(s).  “Change web interface to make customers happy” is not realistic or measurable.  “Increase online sales by 5% by providing customers online discount codes” is a lot better.  Now you have a business goal, you can start asking the question of where do the discount codes come from, how much the discounts are for and how and when they will be input into the system.

If you started with the interface, then the goal becomes short-sighted.  You may not involve anyone in sales.  You likely would not realize that you needed their involvement until late in the project.  They may be only vaguely aware of your project, and they will likely have made assumptions about how it would work.  The end result would likely be that no customer would receive any discount codes, so sales would remain flat in spite of any work being done.

Even worse, if the project sponsor cannot tell you definitively when a project is done and a success, then your project will have constantly shifting requirements, priorities and timelines.  Force the measurements upfront.  This will force any disagreements among stakeholders to be uncovered at the beginning and not at the end.  This will differentiate between a success or a failure in objective terms.

Measurable goals help to define original scope.  One requirements are mapped to the goals, and as long as the requirements themselves are measurable, then original scope is established.  If there is no way to measure it, then the enduser/sponsor will want additional items put in without effective controls.

Posted in PM Basics, Risk Management, Troubled Projects | Tagged: , , , , , , , , , , , , , , | 2 Comments »

It’s Not Just My Opinion

Posted by iammarchhare on 7 May 2009

Someone actually did a 5 part series of articles on “Why Software Development Projects Fail” that states a lot of what I have been telling people for years:  The need for the correct methodology, the need for enduser involvement throughout the length of the project, the need for special care when using distributed teams and the need for visual prototyping.

Although aimed at CIOs, it is a series that any consultant or project manager should read as a review.  Because, your CIO might not have read it.

I guess my only possible disagreement would be whether or not there really is a need for waterfall in today’s world.  However, I readily concede I’ve never worked for NASA, so perhaps it really does work there.

Posted in PM Basics | Tagged: , , , , , , , , , , , , | Comments Off on It’s Not Just My Opinion

Free Webinar on Agile Requirements

Posted by iammarchhare on 24 April 2009

There will be a webinar on Thursday, 30 April 2009 at 2:00 pm EDT on Agile Requirements (Not an Oxymoron).  The speaker will be Ellen Gottesdiener of EBG Consulting.  She is an internationally recognized expert on collaborative requirements development.

I know I’m signing up at GoToWebinar!

Posted in Agile, Training | Tagged: , , , , , , | Comments Off on Free Webinar on Agile Requirements

What Is the Most Important Part of a Project?

Posted by iammarchhare on 22 April 2009

Most of the time, a project manager will say “requirements gathering”.  Once upon a time, I probably would have agreed.  But, I don’t any longer.

Toni Bowers of TechRepublic posted on the IT Leadership blog “Five reasons to discuss project failure”.  She writes:

  1. Failure is instructive. Most of us have an instinctive aversion to discussing weakness, based on concerns that criticism may hurt our pride, reputation, and so on. While I deeply respect these sensitivities, fear creates an environment where repeated cycles of failure can manifest. Breaking this cycle requires understanding the source of problems followed by developing solutions to address them.

Failure causes you to learn.  Hopefully, success does as well.  Humans have an amazing capacity to learn, and we should do so at every opportunity.  If we do not learn, we do not improve professionally or grow personally.

Teams and even companies can learn as well.  That’s why Bowers’ article is so important.  If teams and companies cannot face the facts and learn, then they never improve.  Projects will continue to fail.

A thorough “lessons learned” or “after action” review is a must.  The US Army has a tradition of sending soldiers on field exercises and then holding after action reviews afterwards to grade themselves.  Self-reflection is the key to improvement.

That’s why in the long run requirements gathering just plain is not as important!  Why?  Because a thorough lessons learned review will uncover it as a weakness and make recommendations to fix the problem.  If you do lessons learned poorly or not at all, you will never know if your requirements gathering is any good or not!

What if you had a project to create a product, it was done on time and under budget, it was delivered and the customer never complained.  Was the project a success?  How do you know?

There is a saying that for every customer that complains, there are 9 others who have the same problem but do not complain.  It could be because they are too busy or too tired, or maybe they don’t know who to complain to.  Just because no one complains does not mean the project was a success.  Again, you have to gather data after the main portions of the project have been completed.

The fact that I’ve changed my mind about “requirements gathering” is proof I’m not too old to learn.  🙂

Posted in PM Basics, SDLC, Skills | Tagged: , , , , , , , , | 1 Comment »