pmNERDS Community: Login

  • Innovation_e_Publication
  • Integrated_PM_Feedback_Blog
  • Job_Board
  • pmNERDS_Center_of_Excelence
  • Research_and_Development_Journal
  • Community_Blog
A+ A A-

The Project Charter’s Value Proposition

"If I identify the value proposition for the project, then I provide direction for downstream decisions, but I don’t have any standard way to clearly state it accurately."

The content of some of the boxes change depending on the project, but the placement of the 9 boxes of the Business Model Canvas is the same. I suppose just how you place these boxes isn’t as important as deciding and then sticking to it. A common look between projects helps identify patterns and facilitates comparisons. The critical thing is to address these characteristics about your projects, and provide a quick summary for comparisons.

The first step in the project charter based on the Business Model Canvas is getting to the value proposition. Your project may have other documents like the governance plan, communication plan, and vision scope document; all part of the larger Project Charter. In that case, this might become the summary of the business section of the assembled Project Charter. Depending on your needs this can be stand alone, or a section of a larger document.

Completion of these boxes may be the result of an extensive strategic planning effort, or a 30-minute interview. Get what you can, and then focus efforts on finding the answers you’re not feeling comfortable with.

Within the Value Proposition box, there is the optimal type of proposition to identify and the CORE proposition. Our first step is to decide what type of offering this project will be delivering. Granted, most projects have more than one deliverable. If this is you case, then think of the aggregate of all the deliverables. What is it that you will truly be delivering? Why are the clients coming to you for that deliverable? You want to simplify the answer down to one of three types of value proposition; Unique, Intimacy of familiarity, and cost.

UNIQUE: This is when your project team can deliver a product or service that cannot be acquired anywhere else. An example might be found in an IT organization that provides security credentials that can’t be gotten from anywhere else. You must go to the IT Department for the credentials. Another example could be a sales person’s rolodex full of past clients that can be called on. The company can’t get that unique set of names that can be called on from anywhere else. I’m not convinced of this value, but it is unique. However, typically, the Unique type of proposition yields the premium price. As a project manager and sponsor, you try to create a unique type of deliverable to increase the perceived value of the project.

INTIMATE: This type of proposition states that your project team has intimate experience with creating the desired deliverable. Due to your familiarity of the problem/solution space, your can deliver a product or service better than anyone, or can do it with less errors.

Maybe your intimate understanding will enable you to be more innovative. This type of proposition is a little more flexible than the UNIQUE proposition, and is slightly less competitive. Let’s face it, its hard to prove your better when there are three other teams both internal and external that have an “Intimate” knowledge of the problem/solution space.

Typically, your price point is lower than the UNIQUE type. Understand that price is the total “cost” of ownership. How much pain is the client willing to go through to acquire and own the deliverable. The lower the price you can ask, the better the deliverable must be. The INTIMATE value proposition must be better packaged, better supported, and easier to acquire than the UNIQUE deliverable. Client involvement is normally less, and mostly oversight in nature. After all, you know what they want, even better than they do.

COST: Think ‘Economy of Scale’. You can offer this deliverable faster, cheaper, and at higher quality than your competitors because you do this more often. You do this all the time, and one more just doesn’t impact the cost that much. An example would be a brochure printing. The artwork and design has already been completed. If your already set up, an additional printing just isn’t that much more cost. It’s easy. I call Frank and ask him for 100 more of the brochure. We don’t discuss the layout, the paper size, where to send it- nope its all done. It’s that easy. You just say, “Give me more!”

The ‘Economy of Scale’ deliverable is very desirable, and has the most demand. If using this type of value proposition, you expect to do it a lot, where as the UNIQUE type, you expect to do it less often, and so must charge more, in all aspects of cost.

Now once you have characterized the deliverable, hence the project, as to deliverable type, we want to take a look at the proposition itself. There are five types of valid propositions, you must select one.

MORE VALUE AT LESS COST: This is the easiest proposition to accept, and easiest to prove. You show what new value they will receive, and how this cost less than it did before. I this case, people like to know what has changed. They want to believe you wouldn’t just charge more than you had to. They are looking for a new competency, new technology, or even a reorganization. You need to point to something, and say because of this we can now do that, in order to maintain credibility.

MORE VALUE AT THE SAME COST: This is an easy proposition to accept. It feels like your giving me something for free. Of course, if I value the new free offering, then I will like it. Normally, this can be explained with process efficiencies, so it’s less important to point to the change enabler.

MORE VALUE AT MORE COST: This is a difficult proposition to accept. From the project team’s point of view, it makes the most sense. If you are going to deliver more value, then of course you will need to charge more. Well, you clients don’t see thing this way.

First you will have to prove that there is more value. More value in past offerings may not be so hard, but more value than delivered from a competitor may be difficult to demonstrate, and this proposition becomes expensive fast. Remember, you must justify more cost, and that seldom works out well.

SAME VALUE AT LESS COST: This is an easy proposition to accept. Demonstrate that the change caused by the project does create the same value. Next, demonstrate how it costs less, or is easier to get, or easier to own, or easier to use. Take away the change risk and bam, you got it.

LESS VALUE AT LESS COST: This is a difficult proposition to accept. Know one wants less value, but the real challenge is to demonstrate that the less value isn’t as much as the less cost. You must show that even though you client will lose a little, the reduction in cost is worth it. Prepare for a long adoption process with this proposition.

Continue reading
9 Hits

Create and Leverage Templates

If project managers co-develop standard practices and templates, then practice adoption and baseline performance would be higher, but with so many varying opinions, a ‘We’ culture is required.

Gary stares at his computer monitor, bewildered, as he scrolls through a large folder of project template files, “Just ask the top project managers to share their templates”, he mockingly mumbles to himself. With project performance varying greatly across the different project management teams, Gary, as part of the Governance team, has been tasked with establishing a standard set of project templates to improve project performance across his business unit. Just like a fancy dessert, without a recipe or set of repeatable steps, consistent results aren’t guaranteed.

Creating templates that are leveraged across the organization is something that requires consolidation of input from many sources. Just asking the top performers to give you their templates and combining those into one set of templates, is a daunting task that will not get much buy-in from other project managers. You will get better adoption and leverage of these templates if members of the project management team are involved in developing them. Using a “We” thinking approach and leveraging their diverse knowledge, skills, and experience, you can define much more competitive standard practices and templates.

Even though Gary has been given the authority to define the standard templates, he knows that if he builds them on his own and dictates them to the rest of the organization, not only will very few people adopt them, but they will be much less effective than templates co-developed with the entire team. To lead this initiative, he needs to exercise “We” leadership principles. Key aspects of “We” leadership are to share power, be inclusive, seek feedback, break down silos, celebrate diversity, and encourage discussion.

1) We start by first defining what the characteristics of a good project management process are. 2) Rank these factors based on importance using a simple pair-wise comparison method. 3) We need to define the project phases and their objectives/deliverables. What must we achieve before we move on? 4) Brainstorm on the different tools, methods, templates that could help achieve those objectives. In portfolio management decision making we refer to this step as listing alternatives. Since we don’t have unlimited time, we need to decide out of all the practices we could include in our template, which ones will provide the most value to us.

Using the factors of a good project management practice we defined earlier, we can rank the impact of each proposed practice. When selecting from these ranked practices, the team should keep in mind their current practices and try not to introduce an overwhelming amount of change.These selected practices are included in the baseline template that will be used going forward. This establishes the standard set of practices that Gary was tasked to produce.

By leveraging these standard templates, project performance is no longer solely dependent on the individual managing the project. If we follow the recipe, our desert will turn out well. Performance of your project management teams can now be predicted, measured, and improved. By establishing a fair and inclusive process, that leverages “We” thinking, you can capitalize on the diverse knowledge and experience of your team to create competitive templates that the team is excited to leverage.


Continue reading
156 Hits

Establish Policies & Procedures for Strategic Practices

If we use standardized policies and procedures, then our projects will deliver their strategic intent, but this requires micro-management of projects.

High quality, repeatable, and consistent project performance is a goal of most organizations. Governance, whether in the form of a PMO, Committee, or just policies and procedures, attempts to address this need. The complexity that must be managed for a project to be successful can be overwhelming. For managers to be able to understand correlations and interrelationships between factors in project, portfolio and program management and perform effect-cause-effect thinking that leads to higher levels of performance, the system components must be defined and categorized. Instead of trying to define policies and procedures for every practice and monitor all aspects of the project, the Integrated PM approach to governance leverages system thinking to identify critical variables, leverage points, and constraint analysis to identify the strategic practices that need to be managed through governance.

By boiling down the complexity of your project or portfolio systems to key practices, the overall performance of your organization can be standardized and improved. We attempt to define all the components of your organizational structure that come together to accomplish the strategic goals. Systems Thinking enables a holistic governance while still being able to drill down into smaller components when necessary. Procedures and policies are used to clarify roles, guide practitioners, define state variables used to monitor and manage practices, and provide the desired set of responses to address system constraints and issues.

We develop policies and procedures to ensure that each strategic practice is functioning properly and driving towards its strategic purpose. These policies and procedures define what the practice is supposed to accomplish. The first step is to define the strategic intent of the system, in this case the integrated PM domain, and all the individual practices that make up the system components. Next, we identify the system variables and gain an understanding as to how they interact with, or impact each other. Through systems thinking analysis, we define the process steps and identify leverage points within each practice that will have the most dramatic impact to performance. We set thresholds for these variables and a set of policies and procedures as to how you should respond when certain variable states are reached.

When defining policies and procedures for Integrated PM, the focus should always be on breaking the constraint of the system. The actions and procedures outlined and enforced as part of governance are to guide the project team through the necessary process steps to achieve the highest levels of performance, and will highlight the appropriate responses and actions that should be taken to break the system constraints. When things go off track, the policies and procedures help to identify the issues and propose the procedures that will most effectively address this issue. With policies and procedures defined ahead of time, you will be able to deliver your projects with consistency and continually improve performance.

The END doesn’t justify the means. Getting the project completed doesn’t justify the heroics needed to get there. Policy and procedure get us there in one piece, and enables the organization as a whole to be dependable and perform at predictable performance levels. Governance isn’t micromanagement, it is targeted management. Governance policies and procedures ensure that each individual project team member behaves and takes actions that will deliver the highest performance levels in line with the strategic objectives.

Continue reading
139 Hits

Project Management: Governance & Approvals

“If I want to have a focused project with a uniform approval process, then I need to have strong governance principles, but I am not sure how to build a foundation of good governing practices.”

When I hear, someone mention the term “governance,” I automatically think about men in powdered wigs standing around shouting at each other. I can’t really tell you why my brain automatically goes to the 18th century, but the term, governance, nevertheless speaks to the same set of policies, regulations, functions, processes, procedures and responsibilities that define an establishment, a government governs their people.

In the project world, it is the management and control of projects, programs, and portfolios. In this governance, the goal is to provide clear and uniform oversight of projects at the management level by formal review and strategic decision-making. A review is an assessment by upper management as well as the uniform evaluation of deliverables as they are being constructed.

A good project manager is not only someone that can communicate effectively, but that has the forethought to continuously prepare throughout the project cycle. Good governance has been a serious topic for centuries, so there is lots to it, so let’s put on our powdered wigs and contemplate actions that would build clarity and establish harmony during a project…

As I mentioned before, there are many different types of governance. Corporate governance defines your organizational line of authority and responsibility, the true powdered wigs. You need project governance to ensure that your decision-making process is as streamlined as possible. Establish a clear line between the two. This will help to define your own line of command for yourself as well as your team, because this is not a short process, project governance starts at the very beginning with the business case and continues past the final review of the deliverable.

In the beginning, with the business case document, you are making a case for why this project should be accomplished and what the exact benefits will be. If these points are not stated clearly up front, then there is little chance you’ll gather the support or teamwork necessary to produce a good product, so no point worrying about governance. At the start of every project, you and your team should have and understand this clearly defined purpose. With this purpose, your team has a focus and can, therefore, single-mindedly create goals for the project cycle.

As the primary wig wearer, how are you going to communicate? Who is going to approve what? This should be established early in the project. You should have a communication plan for all key stakeholders, including your sponsor, the client, the team members, as well as all the other important stakeholders. This is sometimes a regular email or meeting, but rather than taking sole responsibility, you can assign spokespersons to key stakeholders, but updates should remain separate from approvals.

You should have a clear division so that when decisions are needed, setup focused sessions with this select group only. If you include decisions into broader sessions which involve your other stakeholders, the session will become more about getting people up to speed, thereby losing focus and negatively impacting your ability to get to a decision point quickly & efficiently. Having both established at the beginning, promotes project confidence and stability, since you won’t be scrambling to put anything together in the middle of everything else.

Even in the 18th century, people had to work for their wigs, because they were a sign of maturity and authority. Attaining a sense of ownership as a project leader is a similar process, but make sure that the team feels that some ownership is important. After you and your team possess it, you have a single point of accountability promoting empowerment and ownership. You successfully ensured that nobody should be standing around confused about what they should be doing. To get that ownership, everyone should know from very early in the project who is needed for which type of decisions and why. By defining this upfront you’re ensuring less confusion further down the line should an issue or critical decision point bubble up unexpectedly.

The formation of good project management practices takes time, and this is just the beginning of true and meaningful project governance. Yet, building a project foundation with these qualities means that your project has focus, and a uniform understanding of what is expected. You want good governance, because it provides you and your team with solid accountability, strong strategies for project formation, honest disclosure, a definite Business Case, as well as the ability to terminate the project. So maybe governance is not all guys in powdered wigs yelling at each other, because the gentlemen of the 18th century did not have true accountability or honest discourse with each other. The men of the wig wearing period did some incredible things, but in regards to governance, the modern project manager has a slight advantage.

Continue reading
126 Hits

Centralized vs Decentralized Product Management

What every executive should know about organizational structures in product management.

In my years of speaking with organizations, one question continues to come up – how do we better align our product teams with the business and development organizations to drive growth. It’s a tough challenge, and one that executives try to address by deciding on if the product management team reports to an enterprise management team, or an individual GM/BU leader. On one hand you can drive a corporate wide strategy and optimize development investments across your entire portfolio. On the other hand, you can get deep vertical expertise to drive change that really moves the needle for a specific business. I always compare it to an age old saying – you just don’t know what you don’t know.

And because of that, I’ve seen organizations switch between those structures, sometimes as fast as every 12 months. That’s a dizzying pace, and I don’t envy the people who have to go through that much churn and change. But like a shark, if you aren’t moving, you’re dead.

Here are some simple guidelines as you think about your organizational structure, and the benefits of each type. And because theory is as good as mud, these examples are based on real life situations on what I’ve seen work, and what has really made a mess of things. It’s brutal honesty, so read on only if you’re prepared to take the sugar as well as the salt.

In theory Centralized Product Management provides:

  • Easy alignment with corporate strategy
  • Cross product portfolio management
  • Identification of market problems that affect multiple business units
  • One face to the customer in terms of common UI, look and feel and interoperability
  • Elimination of costly development duplication

In reality, you can run into the following problems:

  • No one is actually doing portfolio management because it’s too hard, time consuming or there’s simply no infrastructure in place to support it.
  • Collaboration is painful, as there’s no easy way to share information across business units
  • Political nightmare as Business Units that bring in the lion’s share of revenue feel they aren’t getting the attention they deserve, and simply escalate to the executive team immediately

In theory Decentralized Product Management provides:

  • True accountability for a specific line of business and deeper understanding of the P&L
  • Deep vertical knowledge and market expertise for that particular market segment
  • More ownership by individual GM’s, Presidents or BU heads for their contribution to profit
  • Superior, tailored product designs that don’t lose competitive feature differentiation due to generalization and “platformification”.

In reality, you can run into the following problems (I’ll avoid just repeating the above list in reverse):

  • Product Management teams no longer feel responsible to be business owners, as the GM is handling that
  • Complete disarray from everything to common market research activities, to having several “customer focus groups” target the same customer base by different PM teams!
  • Lack of truly game changing transformation for the business
  • No standard process or even the same personal capabilities across the product teams

So in the end, I’d point out two things – don’t just centralize product management because of the capabilities of the product managers, and don’t be afraid of shaking things up as needed. The two structures are very different, and achieve very different objectives. Some just don’t make sense for a certain phase of a company – new markets, big platform needs and lots of acquisitions tend to need more centralized management, while big growth targets, very different market segments and strong business leaders can leverage decentralized product management better.

Good luck – it’s not like a McDonalds franchisee, head office may not always know what they need.

Continue reading
609 Hits