Manage the Requirements, and Let the Project Manage Itself
If you manage the requirements, the project will manage itself.
Well, mostly. You might have to do a little bit more work to truly guarantee success. Showing up on a daily basis is pretty well recommended. And you’ll likely still have meetings that you need to deal with. At the same time, however, managing the requirements well is critical for project success. Do this, and you will succeed. Fail to do this, and I’m afraid you’ll suffer the consequences.
Trust me…I know. I’ve been there.
I first learned this truth after a headlong collision with reality that immediately followed the statement from my sponsor at the time, who uttered those immortal words that cast fear into the hearts of project managers everywhere: “What’s this? This isn’t what I wanted.” After this and similar incidents, I have spent untold hours and days revising and redrafting deliverables, with the constant fervent hope that this time they will meet expectations. Yes, I have learned the hard way that there is a short, steep, slippery slope that leads straight to the land of project whimsy, where success is determined by the irrational and entirely subjective caprice of another human being.
That’s just my pain, mind you. I continue to see grown adults–who should know better–make the same mistakes I have, over and over again. Just like the challenge of trying to teach children that stovetops are hot and you really shouldn’t touch them or climbing that tree isn’t the best idea, sometimes understanding doesn’t seem to jump on board until after a trip to the emergency room. (Or several.)
That this state of affairs should exist in the world of project management is sad. At the same time, it is to a certain extent understandable. Project management as it is traditionally defined doesn’t do an awfully good job at addressing the definition of customer requirements. Specifically, traditional viewpoints of project management presume they are there. The PMBOK has now evolved to the point where it states that requirements definition is the process of managing expectations. But for a lot of us, we still don’t really act that way. Even today, the PMBOK tells you that a fundamental input to the project charter is a defined statement of work, produced by the project sponsor, that never actually gets challenged. Everything else in the process is predicated on that being true.
Until recently, I regularly taught an introductory course in project management that was three days long. In delivering the course, I never got around to the start of project planning until somewhere in the early morning of Day 2. The first day, in its entirety, was dedicated to understanding and managing requirements. Why? Because they are critical. And for the most part, stakeholders have no idea what they actually want out of the project until after they have been forced to confront the reality of what it would mean if they don’t get it. They usually need to be helped, over a protracted period, in really finding out what their requirements of the project really are.
A good recent example of this challenge arose out of a project I managed a few years ago. Specifically, I was awarded a contract to manage a project in response to a Request for Proposals. The RFP process is fairly well understood, and pretty clearly defined: a customer issues a comprehensive statement of the services they want to buy, bidders submit proposals based upon the requirements and the best-qualified bidder wins the work. In this case, I had responded with a proposal that said, in essence, “I don’t really think this is what you want, but to be compliant with the RFP this is what I would do if I were actually to deliver what you were asking.”
In this particular instance, my proposal was accepted. I signed a contract. I went to the kickoff meeting. And after a few well-placed questions, we completely restructured the scope of the project and redefined the expectations of what it was to deliver, all before the meeting was over. By no means was this a normal situation, but neither is it particularly abnormal. It is a result of the fact that many organizations haven’t really taken the time to figure out what problem they are trying to solve, how they would solve it or what it would mean to everyone if that actually happened.
Of particular note is the question of how a project would actually impact everyone. To be horribly, brutally frank, organizations don’t do a great job today about getting everyone to discuss—together–what a project would collectively mean. Instead, requirements typically get drafted by one person or a small core team who–in relative isolation–decide what will be good for everyone else. And while this looks awfully efficient on the front end, because it bypasses all those long, drawn-out, awkward and challenging meetings and debates, it gets awfully expensive on the back end.
At this point in my story, I have an embarrassment of riches in terms of examples I could proffer to illustrate my point. There is, for example, the organization that didn’t really take the time to work through the process changes that would result from implementing a major policy change to how they served their customers. They created a project to implement the systems changes, and quite literally sent out an email to the organization that the changes were complete and they should now go about their business of serving customers in a completely differential manner. There was no guidance, no roadmap, no explanation of the implication of the changes–or why they were being made. And there was certainly no identification–or consideration–of how this would change process, role, structure or responsibility.
I could tell you about the organization that initiated a major change to its operations and implemented a broad set of new systems, assuming they could all be supported through the same structure by the same people, who were heavily invested in doing things the way they had always been done. And who only realized significant benefits out of their investment after years of reactive, after-the-fact changes to roles, structure and usage conventions.
And I could tell you about my personal favorite example, the one where they did invest in significant workshops. Where they consulted broadly with stakeholders, and worked through process and policy implications. Where they designed a comprehensive solution to address the stated problem that the sponsors (for there were multiple) began with. Overall, the consultation process resulted in months of time, and nearly 12 person years in effort, all gone to waste because the stated purpose of the project was something that the sponsor publicly needed to support while privately working to undermine and kill it.
I could keep going on. And I would, except that I would depress even the most eternal of optimists among you. And my editor has a desired word count for this column. The point is that this state of affairs is not new. Organizations are not unique in experiencing these challenges. And project managers are not alone in developing well-advanced substance abuse addictions in response.
It is exactly this state of affairs, actually, that gave rise to the agile movement. They recognized the problems of customers that don’t know what they want–of wasted effort up front describing solutions that didn’t actually address organizational problems. Of mountains of reports and reams of paper attempting strategies that would never be implemented. In response, they said: “Let’s change how we do things. Let’s throw out the whole requirements upfront thing. Let’s get real stakeholders to work with real solution developers, and trust that they will come up with something that works.”
While I get the appeal of agile, what I also recognize is that many sponsors and executives struggle with the concept. Or, more appropriate, they struggle with the whole “trust” thing. They want to know what they are getting up front, and they want a clear understanding of what will be done and how a solution will be arrived at. They want tangible evidence that something is possible. And given the demands for accountability, scrutiny and audit-ability that pervades our current corporate environment, who can blame them?
So what do we do differently? How do we approach this reasonably? How do we get to projects that work? My experience–and my earnestly held belief–is that without investing properly in genuinely defining requirements, projects are doomed to fail. What this means is that stakeholders–all stakeholders–need to be involved in the process from the outset. That real consultation needs to occur on the problems being experienced, and what solutions might be appropriate. That all stakeholders need to align on a common view of the current reality and have in mind what is acceptable in terms of a solution.
This is messy. This is awkward. This involves a lot of meetings and workshops, and a lot of back-and-forth discussion and clarification. It involves seeking to understand first, before advancing potential solutions. It requires recognizing that the best solution for one stakeholder may be the absolutely worst solution for another stakeholder. It necessitates accepting that compromise and give-and-take are necessary, and that requirements negotiation is not a zero-sum game where the winner takes all. Most importantly, it requires recognizing that without first going through this process, committing to the development of a project plan–or worse, a dealing and a budget number–is a consummate waste of time.
When projects get into planning, a transition occurs. What most project managers hold as essential and inviolable is the project scope; every aspect of the plan is in fact driven by that scope statement. The scope statement, however, is the project manager’s translation of the requirements of the stakeholders into the products and work of the project team. It is the requirements that define what the stakeholders genuinely expect. Essential to project success is getting the requirements right. If we do this, the scope should write itself. And the project should pretty much manage itself. Almost.
