After a couple of months, I applied as a cook for a part time evening job that would allow me to take care of my convalescing wife during the day. The Chef asked if I would start by doing the mise en place. Red faced, I admitted not knowing what this job was. Disgustedly, he shook his head, looked over the top of his glasses, and replied, "The two hours of chopping you just mentioned; without it the meal will be a disaster." He was expecting an assistant for preparation; I was expecting a cook. Aligning my expectations to his should have been my first step.
I had failed to do the up-front work of understanding the customer's needs and making sure we were aligned. And, as with any project that starts out this way, the odds of success were predictably low. It was not the expectations that were the problem, lack of alignment killed the deal. Soon I was back to recovering projects that had poor mise en place.
"The customer's expectations are just too high," lamented the project manager with the architect nodding in agreement. I drilled into the comment and realized that the customer wanted features that were beyond the capabilities of the team. The sales team had promised a number of features that would stretch the capabilities of the current technology and no one knew how to tell them it was infeasible.
The elevated expectations get the blame; however, the customer's expectations cannot be wrong, they simply asked for a solution. The overzealous sales team set expectations around the company's capabilities, and the delivery team is in the position of telling the customer the reality of the situation. Executive management calls the sales team into a project meeting and the finger pointing starts. We thought... you said... the competition can... none of which gets the project closer to solving the customer's problem. The real issue is poor alignment between the customer, sales force, and delivery teams.
People having big hairy audacious goals is not a bad, failing to agree on those goals is a major problem. Achieving and maintaining alignment throughout the enterprise is surprisingly difficult. Priorities change, quick answers are given without thorough thought, and consequences of answers are not fully comprehended. Finally, when someone notices there is an issue, people get defensive, thinking there is another round of blame being assigned.
Case Study: It Is Not Always The Customer
On one project, there was a significant division between stakeholders on the rigor in which the development team would implement the requirements. Unfortunately, senior management, believing everyone was aligned, was unwilling to hear that many of the parameters of the project were in contradiction. Three months into the project, new estimates showed the cost and schedule doubling. This was the slap in the face executive management needed to see that stakeholders were misaligned. The price for failing to listen to the project manager was three months of lost time.
There were four distinct feelings about the extensibility of the project's product:
Figure 1: Stakeholder Alignment
- Work on the system should address only bugs and making the system stable.
- When complete, the system should encompass existing major product lines currently not supported.
- Changes should fix the bugs and provide the same look and feel of other systems.
- The resulting system should be extensible and fit with the technology roadmap.
Key is representing this in a manner that shows the degree of misalignment and identifies where to address issues. Besides each stakeholder's opinion on the goal, it is also important to understand how strongly each felt about the need of the category itself. Lastly, it must show the level of consensus within groups to expose the genesis of misconceptions.
Figure 1 shows what was compiled, in retrospect, for this project. It is clear that all of IT (the small bubble shows strong consensus), the group developing the product, had much higher expectations for the resultant system than the rest of the stakeholders. In actuality, the customer (marketing) had bought into the idea of a robust product for the future, but only as a "Nice to Have" feature—far from the "Critical" assignment of IT. In this situation, the supplier had over exuberant expectations.
By the way, I cannot take credit for the presentation format. That comes from Asuret as part of their propriety analysis tools used when assessing a project's viability. This was not generated using their services; however, it is the concept of this type of analysis that is critical in achieving the most favorable conditions for project success.
Mise En Place
Much like dicing up the ingredients before getting the pan hot, project, portfolio, and executive managers must ensure that the prep-work for the project is complete prior to the kick-off. Without assuring all the stakeholders agree on the basic precepts, goals, and objectives, the odds of project success is greatly diminished. Objective analysis is the key to gathering the data without the perception of blame and finger pointing. Assuring alignment does not guarantee a successful project; however, it reduces the chaos in the kitchen when unexpected problems occur.