Sunday, 10 October 2010 00:00

It Is All About Alignment, Not Expectations

Rate this item
(0 votes)

Picture of mise en place

I have always enjoyed cooking and rarely thought of it as a chore, let alone a project; however, when my wife became ill, I became the household chef and had to learn a new way to cook. Every evening was a project with varying degrees of success. Eventually making multi-course meals from scratch became easier. I used to joke that cooking Chinese food was two hours of chopping fresh vegetables and ten minutes with three blazing woks.

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.

Want to read more?

Business environments change daily making it difficult to keep initiatives aligned with the corporate goals. Without alignment the projects and initiatives fail to deliver value. Our Strategic Alignment: The Key To Project Success white paper addresses these issues and what need to be done to thwart them.

Expectations

"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.

Misalignment

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.

Representing Misalignment

There were four distinct feelings about the extensibility of the project's product:

Picture of an alignment graph

Figure 1: Stakeholder Alignment

  1. Work on the system should address only bugs and making the system stable.
  2. When complete, the system should encompass existing major product lines currently not supported.
  3. Changes should fix the bugs and provide the same look and feel of other systems.
  4. 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.

Read 6131 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)

    Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

    No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap