Sunday, 11 September 2011 00:00

Value, the Project Manager's Deliverable

Rate this item
(1 Vote)

A project manager's job is to deliver value. Achieving the original schedule, budget, and features is meaningless if the customer does not receive value. As with all simple statements, this much easier said than accomplished. Projects managers must assemble adaptable teams that use flexible, lean methodologies. Arrogantly selling the latest technology or tool is narcissistic. Focus on the customer. Be vigilant at ensuring the information is always available for the customer to reassess the project's value and for the project team to reevaluate their proposal.


Maintaining Project Value

The first task is determining the customer's initial value objective. Most projects start with the premise that they provide considerable value. However, numerous assumptions are made in justifying that value. Many of these ill-founded hopes fail to survive the test of time, being proven false in the early stages of the project. As we all know, time begets change. Realities adjust as the customer learns about the product's possibilities, business models morph, and challenges arise in building the product. The project must transform to meet these needs and the project manager must lead this shifting vision.

At times, it is more than a gradual shift. Elucidation of major difficulties, discovery of poorly understood requirements, and loss of business segments, name a few reasons to step back and reconsider the project's premise. The most radical change a project manager can propose is terminating the project. Once the projected value falls dangerously close to zero, the value proposition is invalid and the only sensible solution is ceasing the project. This is not failure. It is leadership at its finest.

Want to read more?

Strategy, alignment, communication of goals is not easy. Our Vision To Value white paper talks about focusing your team on the key strategic corporate goals and ensuring everyone in your organization knows the direction.

Facilitating Increased Value

Value is the benefit less the cost. Costs are generally quantifiable; however, benefits are often intangible. Goodwill, trust, esthetics, and usability are but a few attributes that can add significant value to a product. In addition to developing the project's cost, project managers must help the customer enumerate all of the benefits.

For the customer to define value, project managers must supply the information on how the product will or could function. There are no constraints to the original concept, added costs, thrown away work, or extensions to the delivery date. The task is to objectively deliver the complete story and let the customer decide the next step.

This does not mean the project manager does everything the customer asks. The project manager must work with the customer's team and help them create their vision, understand their issues, and guide them toward a solution that delivers a value-laden product in the shortest possible time at the least cost.

Grooming the Team

This does not come from sitting at your desk working with spreadsheets. It comes from understanding the businesses needs, the state of the deliverable, the team's capabilities, and the challenges of selling change.

Developing the customer's confidence and trust is the first step. A cohesive, agile, dynamic team is the primary ingredient in doing so. Integrate your teams with the customer, educate them on the customer's business, and immerse them in the customer's pain. This creates a responsive and customer focused team. It reduces the tendency of teams to build products with the latest gadgets that add little to the value.

Maintaining confidence is more difficult. This requires a culture and methodology that is adaptive. Too many times, we use draconian processes to manage projects—methodologies that strive for operational excellence as opposed to product excellence. Granted, some customers (i.e., healthcare or military) require a thorough paper trail for every functional outcome, no matter how low its probability of occurrence. These are far from a majority of projects. Even in these projects, it is worth questioning the validity of the overhead and proposing new solutions.

Averting Failure

Delivering a project's features and functions on time and within budget is incommensurate with a successful project and a happy customer. Dozens of environmental factors affect a project's value. Successful project managers carefully watch these factors and lead the customer through the process of discovery, defining appropriate changes that maximize their project's value. Losing sight of the project's value will inevitably result in failure.

Read 15003 times

Related items

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

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

  • Disband Your PMO

    After nearly 30 years of project work, I struggle to understand the role of a project management office (PMO). Even though, I have written of the pros and cons, and read a plethora of articles, opinions, and how-to guides little has been done to convince me that the PMO is reducing project failure. It seems to be nothing more than a tool to fill a void in leadership? Even the acronym, which is so widely thrown around, has little meaning as the "P" has no less than four meanings. It is an executive's crutch for their lack of understanding in how projects work. These, like other, unattended holes in the corporate accountability create opportunities for new and greater bureaucracies and empires that further obfuscate accountability.

  • The Catch-22 of Organizational Change Management

    "Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps and they head down the road of failure. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, they did not know, ironically, since there was no procedure in place).

  • Project Inception - Designing Organizations For Success

    Buy it now!

    A failing project’s fate is destined long before assigning a project manager. Its doom is sealed from the time the customer envisions the idea. Traditionally, project inception is defined as when the customer comes to a solution provider (internal or external to their organization) asking for a product or service. In actuality inception is much earlier. It starts when someone says, “Wouldn’t be neat if I could...” From that point forward the customer’s exceptions are set, changed, and reset as the process of discovery refines the concept. The customer’s ideas change from what they want to what they need, while continually constrained and formed by the realities of an ever-changing business environment. Although people cite unrealistic expectations as major problem during inception, the constant change in expectations causes the real issue—misalignment. For project managers to make a significant difference in a project’s success, they must use a new paradig.

Leave a comment

More Info on Project Recovery


Please send me more information on fixing a failing project.

Made with BreezingForms for Joomla!® by Crosstec

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