In project management study after study, results indicate that having a set of clear project requirements improves project success rates. But do clear requirements really guarantee success? What happens when you simply don’t have clear project requirements at the outset? And what does the term clear project requirements even mean? Do clear project requirements have to detail how something will be done?
Like many project managers, I’ve worked on projects with clear requirements that failed miserably, and I’ve worked on other projects with the fuzziest of requirements that were wildly successful. So, why do some people think that clear project requirements are so important to a project’s success? In this blog, I will offer some answers to these questions.
What does the term clear project requirements mean?
In the technology world, the term ‘project requirements’ has come to mean a document that outlines, typically in great detail, the feature(s) that are needed. The document might detail a technology stack to be used, wireframes of user interfaces, details on any API’s that are to be included, and a slew of other technical specifications.
Typically, the better you can outline what you want, the easier it will be for the developers to build it. Yet, the time it can take to outline those requirements can be quite significant. Lean proponents believe that we are better off building small chunks of software, learning from what we’ve built, and then adapting.
In the construction world, the term refers to pages and pages of detailed architectural drawings and engineering specifications. In the construction world, it can take months (perhaps years) of discussions and negotiations, as design teams grapple with the realities of scope and cost tradeoffs, dictated by a limited budget. The process of defining the requirements is iterative and documents are revised frequently.
Software development and building construction are vastly different endeavors. Developers can easily write small pieces of software code that perform a useful function, but a half-built home or bridge is pretty worthless.
So, the takeaway here is that having clear project requirements will vary depending on what kind of project you are doing. I typically recommend that teams focus on defining the what and the why very clearly, and then define the how when that time investment adds value.
What happens when you simply don’t have clear project requirements at the outset?
In other kinds of projects, such as research and development projects, the term ‘project requirements’ may or may not be used. An R&D project is undertaken to solve a problem, such as create a better drug for fighting opioid addiction. No one really has any idea how they are going to do that. The next steps often evolve in response to real-time decision- making. For these kinds of projects, there are no clear project requirements in the same way that there are on construction projects. And yet, for large government funded work there may be copious amounts of detail. I would argue that much of that specification work is wasted time. There are simply too many unknowns and a leaner approach is more effective.
Do clear requirements guarantee success?
While clear project requirements do not guarantee success, many would argue that it helps tremendously. But it depends on how you define success. Gone are the days when success is measured by the triple constraint; that is, finishing the defined scope on time and within the budget. In a world of uncertainty and change, we can no longer afford to spend weeks defining detailed requirements.
So, when you are faced with unclear requirements and rapid change, knowing your what and why is critical. As you think about your upcoming project, ask yourself how you will know if you’ve succeeded. Find a way to measure success. This is typically done at the C Suite, not by the project team.
I find this need to define what success looks like to be especially true for startups. When teams are working long days, some for equity only, it can be increasingly important to define what success means, and then celebrate it when it occurs.
Do clear project requirements have to detail how something will be done?
That depends on a number of things, but the important concept is to know the difference between the what and the how. Finding a drug that will cure opioid addiction is the what. The how will unfold step by step, and simply cannot be mapped out in great detail.
The detailed architectural drawings and engineering specs behind a construction project are the how. The what might be a two or three sentence that defines what you are building.
I would argue that it is critical to define the primary success factor and even your failure criteria. How will you know you have been successful? If a non-profit event raises $100k but the image of the organization is tarnished by drunken guest behavior, was the event successful? When a new technology is being built for a large organization, part of the overall objective is to roll out that technology to full adoption. What good does it do to spend a year and millions on a new financial accounting system if it is never adopted?
Begin with the what and the why. Nail that. Then define how you will measure success. Click To Tweet
Begin with the what and the why. Nail that. Then define how you will measure success. After you have done that, and if you really need a detailed schedule, figure out the how. And, stay as lean as you can — given your scheduling requirements. Need help? Schedule a free call, and let’s talk.