Dealing with unclear requirements
From the Project Discovery Blog
by Anish Abraham
The nature of project work means constantly discovering new problems to solve. So in this blog I'm focussing on discovering innovations, new ideas in project management, also share and learn from others.
Recent Posts
How to start a project that has a relatively low priority?
Dealing with unclear requirements
Choosing the right method for overcoming resistance
Use Of Affinity Diagram As A Brainstorming Tool
Key to Information Management Strategy
Categories
Agile,
Business Intelligence,
Business Requirements,
Change Management,
Communication,
Leadership,
Organizational Project Management,
Process Improvements,
Risk Management,
Stakeholder Management
Date
As project managers we know that one of the greatest challenge in managing projects is dealing with the unknown or unclear requirements. In most cases, project managers fall into the pressure trap from executives and proceed with the project based on their own estimations. I think it's not easy to excuse ourselves by saying that there will be a delay in starting the project because the requirements are unclear. What you think the best way in situations like this?
Go for Agile
Whether it's having unclear requirements, or lack of customer involvement in requirements development, it looks like agile practice can go a long way in mitigating risks. The good thing is that we can start with what we have and go for an iterative development cycle by requesting feedback from customers at every stage of development. And at the completion of iteration, team members can show stakeholders the completed work and review the results.
Try phased
Divide the project into different phases and work with the unknowns. I think when it's broken into smaller pieces they are much easier to tackle. Also, this will reduce risk and also ensure the involvement of the right people at the right time with the right tasks.
Add to risk
When the requirements are not clear we need to record that the estimates are based on unconfirmed assumptions. The next step is to report the risks to the leadership so that the issue can get the visibility and identify any impact to the timeline. Assign an owner and include a resolution target date. If the action owner confirms that assumptions are wrong, we can reestimate with a change management process.
Make assumptions
Normally the PM can start the project with some carefully planned assumptions based on the best knowledge on the domain. Then the team can build the estimates based on these assumptions. The key point is to ensure that these assumptions are available and visible to the project stakeholders, by recording them in the project documentation.
Communicate with stakeholders
As usual communication is the key in project management, so If the project manager does not communicate that the requirements are not clear to stakeholders, then there will be confusion and misunderstanding. Having clear requirements is always important to measure the project success, as it allows the team to compare planned and actual results
Summary
It's very clear from the above discussion that poor or unclear requirements may lead to project delay or failure. Poorly specified requirements can lead to, lost development time, missed project deadlines, poor quality of documentation the list of causes can go on and on.
Posted on: February 03, 2018 07:44 PM |
Permalink
Comments (18)
Please login or join to subscribe to this item
While recording complete requirements is ideal, sometimes it's not possible. As long as you have sign off on those requirements that you have in good faith thoroughly examined with all stakeholders. Then if a new or missing requirement does come up, it won't be such a shock to put it through the change management process. But certainly as you say Anish, gaining clarity in identified requirements is very important.
Anish Abraham
Privacy Program Manager| University of Washington
Auburn, Wa, USA
Absolutely, clarity is very important. Thanks Sante for the comments.
That is a good approach when dealing with unclear requirements to keep the project moving rather than just sitting idle while the clock ticks.
Good article Anish.
Drew Craig
Coach, Practitioner, Consultant, Humanist| North Highland
Philadelphia, Pa, USA
There is much more to it that the requirements - it is also the story behind it. In my requirements documents I would include the 'rationale' with each requirement to provide more 'backstory'. Additionally, in other sections of the requirements document, I would include the big picture overview with workflow states. Both these additions added context for the development and QA team. This is one of the reasons why user stories have significant impact. Its clear business rational allowing the dev team to determine the how without too much minutia. It also, IMO, simplifies the prioritization/grooming activities.
That said, it comes down to conversations/facilitation/elicitation to help shepherd the business through taking there intent/mission/vision to a tangible narrative.
Good topic Anish.
Anish Abraham
Privacy Program Manager| University of Washington
Auburn, Wa, USA
Thanks Drake, for your comments.
Thanks Vincent, I appreciate your detailed feedback on this.
I agree that user stories have significant impact in defining the requirements. One of the benefits of user stories is that they can be written at varying levels of detail.
Drew Craig
Coach, Practitioner, Consultant, Humanist| North Highland
Philadelphia, Pa, USA
Vincent? :) I’ll assume you meant to respond to me....sure, my pleasure!
Anish Abraham
Privacy Program Manager| University of Washington
Auburn, Wa, USA
Hmmm...sorry Andrew it was meant for you.
Ronald Dixon
Healthcare Info Systems Program Manager| AECOM
Garden Ridge, Tx, USA
Working with customers to identify possible non-financial options first sometimes you can save a lot of time and money. The why behind the requirement gives a chance to learn about how our customers operations and organization work to meet internal and external requirements. Anytime a non-resource driven solution is viable that allows the customer to reallocated elsewhere as well as meet the discussed requirement. Not always possible though. Additionally identifying what the customer needs to do when and why to keep the requirement moving towards implementation is a great opportunity for early stakeholder engagement and buy in.
Excellent pointers, Anish.
I would add getting internal stakeholders on board with this approach as it can lead to rework and, consequently, a higher EAC or a delayed schedule.
Such potential occurrences should be baked into the budget and the plan - and all stakeholders need to be kept aware of the amount of potential rework.
Anish Abraham
Privacy Program Manager| University of Washington
Auburn, Wa, USA
Thanks Ronald and Karan for your comments and feedback. I appreciate it.
That was insightful, thank you for shearing
Ronald Dixon
Healthcare Info Systems Program Manager| AECOM
Garden Ridge, Tx, USA
You are most welcome Anish, thank you for the opportunity to participate.
Kevin Drake
Business Manager Electrical Engineering Services | SGS Australia
Perth, Western Australia, Australia
Anish, thank you so much. It is very useful.
Vincent Guerard
Coach - Trainer - Speaker - Advisor| Freelance
Mont-Royal, Quebec, Canada
Unclear requirement could open door to gold plating
Anish Abraham
Privacy Program Manager| University of Washington
Auburn, Wa, USA
Thanks for your feedback, Vincent
This is an interesting article. Thanks!
I'm a Business Analyst and often get into a perpetual cycle of hearing that the "requirements are not clear" :(
When following 'agile' (for the same good reasons mentioned above) there's only so much one could write in the 'acceptance criteria' of 'user stories'. Frequent collaboration in iterative development cycle and early feedback are imperative to meet the 'definition of done'.
But the vendor is looking at that as "requirements change every time!", comparing to the 'acceptance criteria' where those 'feedback' weren't mentioned at first place.
So, a few questions:
1) At the beginning of the project, when the business doesn't know everything about what they want (that makes the scope of work very broad/vague - for which the vendor is supposed to estimate time and cost)
- what is the best project cost model to adopt - T&M or Fixed Bid or something else?
- what is the best project execution model to adopt - Agile or non-agile?
2) Even if the project is kicked-off in one way or the other, someone at some point claims that the documented requirements are unclear, blaming it on the requirements for the deviations from what was delivered against what was expected!
- First of all, are the documented requirements expected to be 100% clear upfront in a way that no one can misinterpret them? Is that even possible?
- What factors would cause someone to claim that the documented requirements are unclear? Is it human factors like- limited ability to comprehend the requirements/failure to see the big picture/inadequate technical analysis or factors like ambiguous statements' or something else?
- Either way, how to make sure that the documented requirements are clear for everyone in the project, such that no one can blame it on the requirements?
o Similar to business sign-off, should there be sign-off from other stakeholders that they understood the requirements as they were intended to be?
o Similar to documented requirements provided by the business should there be something like a documented solution/tech design approach provided back to the business that helps validate the understanding ?
- For those whore claiming that the requirements are not clear, what should they do to gain clarity over the requirements (rather than just expecting the requirements to be magically clear ) ?
Appreciate any thoughts :)
Luis Branco
CEO| Business Insight, Consultores de Gestão, Ldª
Carcavelos, Lisboa, Portugal
Dear Anish
Interesting your perspective on the topic: "Dealing with unclear requirements"
Thanks for sharing
Important point to remember: "Having clear requirements is always important to measure the project success, as it allows the team to compare planned and actual results"
Thiha Ko Ko
Head of IT| Partner Associates Int'l
Yangon, Yangon, Myanmar
Please Login/Register to leave a comment.
|
"Nothing so needs reforming as other people's habits."
- Mark Twain
|
