Making the Most of Bad Requirements on a Project

Good, complete, complex and well-documented requirements are the lifeblood of the project. With them, everything can run pretty smoothly for the duration of the project.

Design and development by the delivery team is dependent on them… so a good, workable solution is dependent on them. As is usability of the end solution by the end user population, right? So far do I seem on track as to the importance of good, detailed project requirements? What else? User acceptance testing (UAT) will have a tie in as on tech projects especially that is where testing scenarios and test cases will be built from and against. So a good user acceptance testing experience and confident outcome is dependent on having good, complete and well-documented requirements, right? Meaning final signoff on the project by the customer is at stake too…

So what happens on projects where requirements aren’t or couldn’t be documented well? What if the business processes or the project need is a bit unclear, so the project starts without well documented, complex and detailed requirements. Come on; we start long trips this way so why not projects? After all, aren’t truly full documented requirements in a very detailed form more of a luxury than a given?

How many of us have had everything spelled out as to what is needed to be accomplished before embarking on a project engagement? There comes the point when we’ve done enough planning – or really when we’ve spent enough project dollars and time planning and detailing requirements. When is that? When management or the customer sees from the budget forecast and project timeline that all of the planned efforts for requirements has been expended and that begin saying… “let’s get started already!” When this happens… you don’t have much choice… you move forward but keep these things in mind…

That re-work is possible and likely.

Whenever we are faced with vague issues during planning, then re-work during the project is possible and probable. Maybe the business processes are poorly defined, or the customer isn’t sure yet what they want (they will know it when they see it) or some similar scenario. Whatever the situation, when you’re building a solution with a roadmap that has gaps in it, you’re going to have some bumps in the road. Document whatever you can as potential risks, track all schedule deviations and manage project scope closely. Change orders are necessary for almost all projects, but we always try to keep them to a minimum so as not to risk issues with the project client. But they will be more likely on a project like this… which leads to my next topic…

Change will happen.

Yes, on a project with less than fully documented requirements, change will happen. Clients usually aren’t too happy to hear “change order!” shouted from the rooftops, because it usually ends up meaning they have to pay more. But on a project like this, you have to make it very clear as the planning phase is closing and your client is pushing forward that the risk is high for re-work and the need for scope changes and change orders. If you’ve softened the news by declaring that early on, then the customer impact will hopefully be minimal and resistance to the change orders non-existent.

Timelines will move throughout the project.

With re-work and change orders comes timelines and dates missed or moved by the change orders. The impact can be worse than just changed dates and dollars though. It may mean you lack project resources to get the work done due to timeframe shifts or additional resources needed to cover new work that wasn’t originally planned. So onboarding, learning curves, and revisions to existing plans could all be necessary. Be prepared for this mess, because it could quickly derail the project if not monitored closely.

The budget must be monitored very closely.

I’m a proponent of watching the project budget extremely closely – to the point of forecasting and re-forecasting on a weekly basis. As I always say, “a 10% budget overrun is not too hard to fix and is usually deemed acceptable… but a 50% overrun is nearly impossible to recover from and may result in a failed project.” So, watch the budget closely – always, but especially on this type of project where expenses could mount fast – and you may be able to keep it on track. At least you’ll be able to raise the financial flag early and possibly fix the situation with a well documented and planned change order to cover the extra effort and expense as they are happening and not after the fact. It’s all part of that oh so fun project management responsibility called scope management. And never is it more apparent and needed than on the project that starts with poorly defined project requirements. So, good luck! You’re going to need it.

Summary / call for input

Starting the real work on any project knowing the requirements are more like Swiss cheese than you are comfortable with is a source of major concern for the project manager and team. It will take skilled leadership and customer oversight to keep the project on track and somewhat on time and on budget. This is not for the faint of heart nor is it a great situation for a less experienced project manager. If you can avoid one of these risky situations, do so… run. But since you likely can’t, and you’ll probably feel the adrenaline flowing for the challenge of it all, we push forward and seek project success where it may be very difficult to find. Plus, we may have been assigned to it for a reason and have no option but to make the best of it.

Thoughts? Have you been involved in many projects with vague or poorly documented requirements? Why were the requirements so bad or hard to collect? Was it a new technology or customer not really knowing what they really wanted? Please share your thoughts and experiences.