When it comes to the conversation between a project management team and a client, many complaints lead back to the same root cause: failure to manage expectations. Here, Payson takes a look at some of those complaints and reminds us that work product definitions aren't the enemy.
While consulting recently on a $50 million IT project, I had occasion to talk with several members of the development vendor's project management (PM) team. It was early in the requirements/design phase of the project, and the vendor team was exasperated by our mutual client's insistence that a document be created and approved describing the format, content, and applicable standards of future vendor work products like the "architectural specification," "training plan," and "detailed design."
"This busy work is driving us crazy," they said, asking if I might intervene with the client on their behalf and encourage the client to waive the need for some of the "documents describing the documents" so they could "get on with the real work." The vendor's PM staff seemed competent and earnest, but their attitude betrayed their lack of experience on large, fixed-price contracts.
I've been building systems (and doing autopsies after others' failures to build systems) for over twenty-five years. The biggest problem I have observed isn't an inability to do work or solve tough technical challenges; it is the failure to set and manage expectations with clients about the work products they can expect, the boundaries and limitations of those work products, why the work products are valuable, and how they advance the cause of the project.
Failure to manage expectations is often a root cause of project failure that leads to the more familiar secondary causes that people complain about. For example:
"Requirements kept changing!"
Welcome to Earth. Requirements evolve as project participants better understand the problem and the solution. It is imperative that everyone is on board with the reality that all change has cost and schedule implications. To have an intelligent discussion about change, there must be an agreed-upon baseline definition. This often takes the form of different project work products that establish boundaries. Everyone must agree what these documents will contain, what they won't contain, and how they will be structured; otherwise, expensive disagreements may emerge if clients feel that work products are incomplete or too "high level" and developers feel that the client is being fickle and moving the goal posts.
"Everything was going fine until the new (unreasonable) client joined the project."
There are unreasonable people in the world, but most people assigned to a project are interested in helping it succeed. When people seem "unreasonable," it is often because they are frustrated or concerned that things aren't going well or that someone is trying to take advantage of them. When I join a project, one of the things I do is review previous work products to get up to speed. If the criteria and purpose of a work product are clearly established, I know what to expect and can assess it fairly. If the criteria and purpose are ambiguous, I quickly become suspicious, leading to ...
"Things started well, then trust broke down."
I'm not a suspicious person by nature, but remember: The majority of large IT projects fail to deliver on time and on budget.
If you are cynical, you can just assume that any large project you encounter will be late and over budget (or fail outright). You will be right more than 60 percent of the time. Experienced people look for periodic, tangible reassurance that the project remains on track. Tangible reassurance typically takes the form of work products created during the journey that continually refine the vision and scope.
"It took the users forever to sign off on the system."
Nothing encourages people to pay attention like asking them to take responsibility by signing something that says they accept it and all their concerns have been addressed. It is in everyone's best interest if acceptance is sought incrementally, rather than pushing it off to the last-possible moment. Work product descriptions encourage up-front consideration of what a deliverable will consist of and give people a chance to think it through before a huge effort is made to create a deliverable that people may not agree upon.
The Bottom Line
Work product definitions are your friends. At the start of a large project, it is often difficult to envision the details of the work products that will be created. The contract may outline deliverables and applicable standards, but as the work product looms on the horizon, it is often in everyone's best interest to revisit, amplify, clarify, and refine the work product description and seek agreement before much energy is expended creating the work products themselves. This provides an opportunity for negotiation or clarification to assure that everyone is on board and that expectations are managed.
