New WWYD series: Requirements Unpreparedness

08/29/2011

8 Comments

 
Picture
I've been asked by PMI (the Project Management Institute) to create an article for an upcoming series on basically this very concept.  Sort of a "What Would You Do" topic where I discuss an issue I came up against during a project, how I handled it, what the outcome was, and then I call for responses.  The idea is to generate a community discussion so we can all learn from each other's responses on how each of us handled a similar situation or how we might handle it if faced with something similar in the future.

So, I thought this might be a nice ongoing series that I present here as well.  I may or may not present something from my past experience or from a colleagues past experience - it may be real or made up.  And if any of you want a situation or incident discussed on here, just email me and I'll use it for an upcoming topic.

I'm not yet sure how often I'll do these - I'm thinking possible twice per week.  Today's installment is about requirements...a touchy subject for all, I'm sure.

Scenario:  You're starting a project, you have  schedule and price in place and you sit down with the customer and their team to review the detailed requirements that they say they have and that the schedule is built around.  What you find out, though, is that their detailed requirements are really very vague, high-level requirements that will require much more detail and thorough analysis before you have anything useable to build a solution from.

The impact, of course, is that you have the schedule and a price for the project that is based on the fact that you won't have to do this further detailed requirements planning and documentation with the client...they indicated they had detailed requirements as the deal was closed.  But they don't.  What do you do next?  Do you put the project on hold till they have the requirements?  Do you go back to the account manager and have them rework the deal?  Do you create a change order to cover the extra planning time?  Keep in mind - this is the first  PM-customer interaction and starting off with a change order or demand for more money may not sit well with them... it must be handled carefully.

Looking forward to your respones...thanks.

 


Comments

Keith Richards link
08/30/2011 02:15

A lot depends on whether or not the customer is naive or clever. A clever customer would realise that the detail of requirements comes out later rather than sooner. A naive customer would think they know the detail in advance. Methods such as DSDM are built around the concept of requirement detail emerging as work progresses.

Reply
Peter Westerhof
08/30/2011 05:11

The story of my professional life.

First of all, obviously schedule and price weren't drafted by you based on the requirements. So you would be executing activities instead of running a project.

But bottom line is, if you don't have clear requirements you don't have a clear understanding of what you want, so you don't have a clear understanding of what you will get, so you won't know what you have once you get whatever you get, so you can't have it properly checked whether it does what it is supposed to do, so you'll end up either accepting something that does something that looks like it does what you thought you wanted but not entirely or you can refuse it because you don't like it without being able to explain why.

If you think the previous paragraph was complicated, just start a project without proper requirements and find out. Or see if it stands up in court. Either way it's going to be expensive.

Reply
Koushal
08/30/2011 11:26

I am in a similar kind of situation right now. I have allocated considerable time for Requirements Gathering &Impact Analysis. Also, another constraint that I have is end date is non-negotiable. I would be fast tracking the project. Its risky but there are business demands that you need to take into consideration and mitigate the risk as much as possible

Reply
Terri Edney
08/30/2011 17:21

I don't think I could have agreed to start the project without seeing the requirements. Price and Schedule are based on what is derived from those requirements.
Having worked for someone who would have assigned the work to me, having signed a contract without seeing the requirements, I think I would take a little unpaid time to work through the first part of the requirements to show the client the lack of detail and try to convince them that more time needed to be spent on the detail.
If money was the limiting factor, I would look to compress the schedule in other areas to make time for the requirements gathering. More planning up front means less mistakes in the end, and happier customers. (Then I would have words with the person who signed the contract without reviewing the requirements!)

Reply
Nick
08/31/2011 00:23

A large part of a PM's role is to educate the 'business' on what a project is, how its run and why the various items you will have discussed are needed to ensure what is delivered meets their needs .... people seldom know what they dont know and PM's often take for granted what is needed. I would be inclined to explain the issue to them either picking several of the high level reqts and explaining all of the detailed that is needed (show them what they dont know) or flash up a set of reqts from a similar project (show them what good looks like). At that points its your call as to whether you feel you run a risk to your professional reputation by carrying on and / or if you have the legal right to exit if you do. I would always 'buy' the PM who had the courage to save a firm money by stopping a project failing form the get go and conversley would never go near the guy again who just took his money even though he knew it would fail.

Reply
fran
09/01/2011 01:51

experience has told me that the customer, if given an end date will expect it to be met. If requirements are not clear(as opposed to being in insufficient detail), then the next (stage of the) project is discovery/requirements gathering. There used to be formulae for working out a project delivery based on the duration/effort of requirements gathering, but I have not seen any recently. These are built up over time by analysing your site/customers/development tools and how they did in the past.

If you are taling about reqts lacking in detail, then a rule of thumb is that delivery will take from 30-60% more than your high level estimate, but you will also have to factor in the willingness of the requestor to actually spend their time to clarify requirements.
Prototyping, first cut design can assist this, if the customer has only outcomes.
If you are limited in time/resources/price, then you only approach is a scoping/scope limiting exercise - gather all the wishes, and prioritise

Reply
Vicki link
09/06/2011 18:21

I agree that agreeing to a budget and schedule prior to seeing requirements is a huge risk. Perhaps I should have to eat some. But that aside...

I would take a step back and work with my project team to do some proper scope planning starting with a deliverables based WBS. With this we can start planning the activities and all that goes into collaboratively developing a schedule. We should be able to determine a few options to present to the client; 1) phased implementation focusing on core critical functions only initially then adding on at time and money allows (same money time, less functionality, 2) adding one or more resources to get ahead of the development curve and refine the requirements (more money, not much more time), or the team work towards refining requirements taking time from development (more money, more time). A more controversial approach may be to design only the bare bones minimum of the requirements. If there are that vague no special features (e.g., spell check, rich text formatting, date picker) have been documented, so you deliver a bare bones, may or may not be usable solution while claiming each design decision is a requirement subject to change control. I don't really like that approach, but I may offer it up as option #4 to the sponsor in the previous discussion.

Reply
sherry
10/17/2011 03:25

i would work hard with a business analyst on the client's cost to document detailed requirements. and get a sign off on that. if this does not work then you really need to raise this shipstopper to stakeholders of the project and halt project until the issue is resolved.

Reply



Leave a Reply