Tag: Facilitation

OUTSIDE THE BOX Forum: CMMI Maturity Levels 2 and 3 Should be Revised to Make Sense for the Hybrid Project World

Written by Robert Wysocki on May 1, 2018. Posted in Articles. 9 Comments on OUTSIDE THE BOX Forum: CMMI Maturity Levels 2 and 3 Should be Revised to Make Sense for the Hybrid Project World

For several years now the SEI Capability Maturity Model has been widely heralded as the ideal descriptor of the state of project management maturity in the contemporary organization.

Level 2: There is a standard methodology in place and Level 3: Documented Process that Everyone Uses have been the goals for all to achieve. Operating at Level 3 projects can be effectively executed and managed to produce the expected business value. That may be true, but its adoption statistics are disappointing. Mark Mullaly reports [Mullaly, 2017] that less than 2% of organizations have reached Level 3 or beyond. Based on Mullaly’s data most organizations operate at Levels 1 and 2.

So, faced with the preponderance of Maturity Level 1 and two organizations how could CMMI adapt to maintain its relevance to Hybrid Project Management? This article answers that question.

THE HYBRID PROJECT WORLD

The Hybrid project landscape defines the types of projects that have challenged the project management community for nearly 30 years because the commercially available Project Management Life Cycle (PMLC) models do not align well with the constraints placed on these projects:

the physical and behavioral characteristics of the project
the cultural and organizational environment in which the project will be executed
the changing market situation where the deliverables will compete

That lack of fit between the PMLC model and the project is reflected in 2/3 of the projects having failed or challenged. Hybrid Project Management has been below the radar for years. It is a fact of life, and the Capability Maturity Model Integrated (CMMI) has not yet responded and seems to be dismissed as irrelevant. That is not good for the long term. How can the CMMI reply?

THE DESIRED END STATE

The desired end state in a Hybrid Project Management (HPMgt) environment includes a vetted portfolio of tools, templates, and processes that can be used by a Hybrid Project Manager (HPMgr) to design and maintain the alignment of their project management approach to a specific project based on the three constraints listed above.

The success criteria for complex projects is the attainment of the expected business value that justified the approval of and resources to support the project. That success criteria will be one or more of the following metrics:

Increased Revenue (IR)
Avoidance of Cost (AC)
Improved Service (IS)

The criteria are defined by the well-known acronym IRACIS.

Advertisement
[widget id=”custom_html-68″]

The complex project landscape was not defined nor understood when the Capability Maturity Management Integration (CMMI) was introduced. That raises the question of its applicability to HPMgt and effective use to the HPMgr. Given the survey results reported by Mark Mulally, it doesn’t seem relevant. Hopefully, that is a temporary problem and can be solved with a meaningful revision.

CMMI Maturity Level Definitions for Hybrid Project Management

The Software Engineering Institute (SEI) at Carnegie Mellon University introduced the Capability Maturity Model (CMM) in 1987 and the CMMI in 2002. It has become the de facto standard for measuring the maturity of processes and the practice of those processes. But it may have reached its half-life. How might we define the maturity levels to align with HPMgt needs?

HPMgt Maturity Level 1: Ad Hoc or Informal

Basically, everyone is managing projects their own way – a Do It Yourself model. They may be using tools, templates, or processes that they developed, discovered, or borrowed and have been in their toolkits for years. There may be some common practices in the organization, but these are not fully documented or supported—just expected. I have often seen organizations provide a collection of templates as suggestions, not requirements. This may not be as a chaotic environment as you would expect. Give the HPMgr the credit for being intelligent enough to recognize the management tools, templates, and processes that they need and build them into their ad hoc approach.

HPMgt Maturity Level 2: Documented Processes

At Level 2 maturity, the tools, templates, and processes for managing projects have been defined and documented. Level 2 is an interesting level of maturity, not so much regarding what the documentation says, but how it was put in place. Obviously, the motivation for doing the documentation is that the organization expects its project teams to implement the documented processes. It is beyond the scope of this article to talk about how the documentation was created but let me say that if you expect someone to use your stuff, you had better give them an opportunity to participate in its development. Don’t risk the “not invented here syndrome.” This must be a team effort to have a chance at success.

Within the context of HPMgt Maturity Level 2, if the tools, templates, and processes have been vetted by the PSO and are a complete portfolio, then the HPMgt needs of the HPMgr would have been met. But that is just the beginning of the story. Given the unique needs of the project it is unlikely that an off-the-shelf tool, template or process can be aligned. In almost every case it will have to be adapted to the uniqueness of the project. Rules for that adaptation may be part of the documentation.

HPMgt Level 3: Documented Processes That Everyone Uses

Compliance to this extent is not a realistic objective. Uniqueness is the obstacle. Stop and think about it for a minute. Is it possible that the developer of any tool, template or process could have envisioned and met all possible variations? Not likely. At Level 3, documented tools, templates and processes are vetted, supported and maintained. Compliance comes in many forms. In the complex project, landscape compliance must allow the adaptation of a tool, template or process to provide the best fit of the HPMgt process to the three constraints on the project. This is far more flexible than the original intent of Maturity Level 3. The PSO has to be open to suggestions for improvement from the HPMgr community and have a formal process in place for receiving and acting upon those suggestions.

HPMgt Level 4: Integrated into Business Processes

The HPM world is one of collaboration and meaningful client involvement. The client is both outside the project team (i.e., like a stakeholder) and inside the project team as an active member. So, business processes are already integrated into the HPMgt Framework. This is best described by saying that project management has a seat at the business decision-making and planning table. At Level 4, effective project management is recognized as a critical success factor and a strategic asset to the organization. It is considered to be part of every business process or decision and a contributor to business value.

HPMgt Level 5: Continuous Improvement

Maturity Level 5 is the pinnacle of integrating project management into the business. There is a formal and continuous program in place for process and practice improvement. It runs throughout the entire project life cycle. It formally begins with project execution and continues through to the post-implementation audit and lessons-learned exercises at the end of the project. At Maturity Level 5 there is a way to capture these ″best practices″ and integrate them into the recommended tools, templates, and processes. At Maturity Level 5 every project team is constantly on the lookout for problems and offers suggestions for improvement.

THE ROLE OF THE PSO IN HPMgt

In the short run, the best senior management and the Project Support Office (PSO) can do is provide a resource to support the hybrid project teams. To maintain some semblance of control that resource should be a portfolio of tools, templates, and processes for managing the project over its life span. To further maintain comparability of performance between projects that resource should be vetted and the HPMgr encouraged to use only the vetted portfolio over the entire project life cycle.

The PSO will play a pivotal role. They will need a collaborative effort with the HPMgr community to build that vetted portfolio and then follow that up with a program that encourages project teams to use that vetted portfolio. No small task! I have previously written about that vetted portfolio [Wysocki, 2014]. Project managers must see that there is value in using the vetted portfolio because it is a supported portfolio. They are more likely to be users if they have participated in its creation and maintenance.

The Vetted Portfolio

The major strength of the HPMgt environment is that it places full control over the management of the project in the hands of the HPMgr. But that control would be a ticket to chaos if it weren’t contained within a portfolio of vetted tools, templates and processes. Having that portfolio in place and used presents several benefits and challenges to the organization:

the portfolio contains all of the tools, templates, and processes that will be needed to satisfy the management requirements of any project that the organization might encounter.
the portfolio includes a continuous improvement process that monitors project performance and provides an open environment for project performance enhancements
the HPMgrs have a detailed working knowledge of the portfolio and how to adjust it to satisfy any project management requirements that might arise
the HPMgrs have the authority and responsibility to do what makes sense for effective project management

PUTTING IT ALL TOGETHER

CMMI was built for the Industrial Age project. We are in the Information Age. Maybe we need to rethink the CMMI in light of the movement towards a collaborative project management environment. The question to answer is “What is CMMI Level 3 Maturity in HPMgt? Rather than requiring compliance to a documented methodology, it should define the methodology based on the characteristics of the project, the organizational environment and the dynamics of the market situation.

END NOTES
[Mullaly, 2017] Mullaly, Mark. “All is Not the Same in the World of Project Management (Projectmanagement.com), March 27, 2017.
[Wysocki,2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing

Speaking Truth to Authority – Criticizing and Contradicting Your Boss

Written by George Pitagorsky on January 29, 2018. Posted in Articles. 12 Comments on Speaking Truth to Authority – Criticizing and Contradicting Your Boss

At a team meeting, your boss comes up with an idea for a new way of performing your team’s work.

While the idea has some merit, it does not really work given real-world conditions. What do you do?

What if your boss frequently sends double messages – one day she praises a work product and a week later uses it as an example of how you and your team need to improve your performance? Or, if he is constantly making your job harder by putting up roadblocks or not protecting you and your team from the roadblocks that others put up.

Contradicting the Boss

One of the most anxiety producing situations at work is criticizing on contradicting your ‘boss”. When you are a project manager or business analyst, your boss may be a manger, sponsor or client, or all of them, to one degree or another.

While it is generally viewed by management experts that it is your boss’ responsibility to create a safe place for such confrontations, how often is that found in the real world? It is up to you as an individual to balance the values of being candidly truthful and maintaining a good relationship with your boss. Of course, the same thing is true for anyone with whom you have a relationship, though for this article we will focus on the relationships in which you are subject to your boss – a person who has the power to fire you or give you a performance review.

The Benefits of Truthfulness

In general, being candidly truthful is beneficial. Individuals, teams and organizations optimize their performance when constructive criticism or opposition is offered and received in the spirit of continuous improvement. The Abilene Paradox is a wonderful reminder that withholding negative input makes it less likely that problems will be avoided, and optimal solutions found. It reminds us that it is everyone’s responsibility to speak up and provide their views.

Yet, there are limits. Personalities and psychological tendencies can get in the way. Some people take any kind of criticism or opposition as an attack and a sign of disloyalty, becoming defensive and angry. That is bad enough if the person is a peer or subordinate, but when it is your boss, you can be fired, given a bad review, labeled as a trouble maker or just told you to shut up and follow orders. That being so, fear gets in the way of being candid.

Navigating the tricky issues of managing the relationships in hierarchies is more of an art than a science. There are no easy formulaic approaches, though there are some guidelines and skillful practices that will make the task easier.

Four Questions

Before giving feedback – critical or otherwise – address these questions:

What are you criticizing?
What is your motivation?
Will it do any good?
How will it be perceived?

Advertisement
[widget id=”custom_html-68″]

Criticize Things, NOT People

Criticizing a person generally results in defensiveness. Separate the source, the person who created the thing in question, from the target. Criticize an idea, a statement, behavior or work product as opposed to a person. The person is the source but not the thing itself. Changing behavior or the content of a document, as hard as it may be, is far easier than changing character.

While the source may identify with his or her creation, you must separate the two. When you do, you are able to assess the situation and communicate so as to minimize personal attachments.

Ideally, the issue of not identifying the issue with its source has been addressed in a training or team building exercise. That way it is possible to remind one another to promote objectivity to achieve improvement. But, remember that even then the author is likely to be somewhat attached to and identified with his or her result.

Motivation

The question of motivation is an important one. Are you criticizing an idea or action because it makes you feel smart and important or because you are trying to help the other person, the team or organization? Is anger or frustration driving your need to criticize? Is fear the reason you are holding back?

The ideal motivation for giving critical feedback is to promote improved performance. Though, often, there is a combination of motivating factors. You may feel frustrated or motivated by showing how smart you are and, at the same time, think that what you have to say is beneficial. That is where the next question comes in.

Will it Do Any Good?

Will your criticism have a beneficial impact, will it change behavior so that the result is a better deliverable or a more effective process?

Even when there is a likelihood that what you have to say is beneficial, you still must consider the risk you are taking vs. the reward. Here is where social awareness comes into play. Social awareness consists of the ability to sense what others think and feel and an awareness of organizational norms and relationships.

It is in anyone’s best interest to be open to useful criticism, simply because it gives them the ability to reflect on their idea or behavior and opt to change it. Though, there are those who don’t believe that and feel that criticism is an attack to be defended against.

How will it be perceived?

How your criticism is perceived strongly influences whether what you have to say will have a positive effect.

For example, if your social intelligence tells you that your boss is averse to any kind of criticism or that you are in an organization in which any criticism from a subordinate is culturally forbidden, no matter how accurate and perceptive your criticism is, it will not be perceived well and therefor will not have the beneficial effect you intended it to have.

How to do it?

Having assessed the situation and made the decision to go ahead and give your input to the boss, do it skillfully.

Timing is critical. Depending on your organizational culture, it may be perfectly acceptable to have your say in public, as the idea is being aired. In other situations, you will get better results if you take your boss aside and have your say one-on-one and doing it in a way that will allow your boss to come back to the public forum exhibiting his intelligence and ability to critically reflect on his or her own ideas and change his opinion.

Whether in private or public, send ‘I’ messages. “I think there may be a more effective way to handle this, because …” as opposed to “your idea has some flaws.”

Stick to facts and objective criteria as opposed to unsubstantiated opinions.

Ask questions like “Have you considered X as an alternative?” or, “What would happen if ‘Z’ occurred?” or, “What were your decision criteria?”

You might also begin your criticism with some praise – “What a creative idea?” – before getting into the meat of your input. Close with something positive, like “Do you think we (or you) can resolve the problem more effectively by looking at some of these options?”

In the end, well-meaning criticism, presented skillfully, sensitive to personal feelings and cultural inhibitions, is a means for continuous improvement.

OUTSIDE THE BOX Forum: Mastering the 10 Challenges to Agile Portfolio Management

Written by Robert Wysocki on November 14, 2017. Posted in Articles. 13 Comments on OUTSIDE THE BOX Forum: Mastering the 10 Challenges to Agile Portfolio Management

Agile projects are those whose goal and or solution are not clearly defined. These projects dominate the project landscape.

Usually some agile or extreme model is used to manage them. They are high risk, high change and their outcomes are not at all certain. Managing portfolios of these projects is very complex and will challenge even the most experienced among us. In priority order the major challenges are:

Organizational support
Project governance
Measuring performance
Meaningfully involving clients
Structuring the project team
Estimating business value
Eliciting requirements
Scheduling constrained resources
Improving process design
Improving product design

This article describes each challenge and offers strategies for dealing with each one.

ORGANIZATIONAL SUPPORT

Organizational support extends from the very highest management levels in the organization all the way down to the project sponsor and the management team to whom the project manager reports. A Project Support Office (PSO) should be in place to offer not only the vetted processes and practices that are needed in an agile environment but also the training and consulting support that a complex project manager and team might require in the discharge of their responsibilities.

PROJECT GOVERNANCE

Complex projects are high risk projects. To mitigate some of that risk decisions should be made as close as possible to the expertise for making those decisions. That responsibility should be assigned to the team. But not just any team. The only decisions that should be made above the team level would be those decisions to adjust priorities, postpone the project or terminate the project.

MEASURING PERFORMANCE

The one common thread that links all projects is the business value that each expects to bring to the client and the organization. Business value would have been the deliverable that was used to approve the complex project and its plan. That might seem like the problem has been solved. Don’t be too quick to judge however. There is much yet to be done. Project performance is the variable that we will use to compare each project, program and portfolio in the enterprise portfolio. That comparison will be used to decide project status for the coming iteration. So we have to include not only past performance but also the prospect for future performance.

MEANINGFULLY INVOLVING CLIENTS

In the traditional project world clients were involved at the requirements elicitation phase and after that only for status reporting and deliverables approval. In the complex project world that is no longer effective. In its place the client must be meaningfully involved even to the extent that they will have management and decision making authority as members of the project team. They are the product experts and will have responsibility for managing the deliverables. The process expert on the team is the traditional project manager. They and the product manager have co-equal management responsibilities for the project.

Advertisement
[widget id=”custom_html-68″]

STRUCTURING THE PROJECT TEAM

To be most effective a complex project team should count among its members those who possess all of the skills and competencies needed to succeed. That includes the decision making needs of the project. The project team template is shown in Figure 1.

Figure 1 ECPM Project Team Template

For a detailed discussion on the Co-Manager Model see Strengthening Client Involvement in the PRINCE2 Process Using the ECPM Co-Manager Model, (PM Times Oct 24, 2015 and PM Times October 28, 2015).

ESTIMATING BUSINESS VALUE

Every project is approved based on the business value it is expected to deliver. In the complex project world the solution is usually not completely known at the outset and must be discovered through iteration. That makes the expected business value that will be delivered very difficult to estimate. As iterations proceed the estimated business value may be different than the expected business value of an acceptable solution. The estimated business value that a project will deliver is often the primary factor underlying approval of the project business case. In a complex project that is seldom more than a best guess. As the project work commences and the solution begins to take shape that estimate is revised. It can change and so can the priority of the project.

ELICITING REQUIREMENTS

In the complex project world it may not be possible to elicit complete and clearly defined requirements. This step is designed into the ECPM Framework. The design is a two-step process that totally eliminates the current problem of incomplete requirements. The first step is a high-level identification of the set of necessary and sufficient requirements for achieving the expected business value delivered by an acceptable solution. How these requirements will be met is left to the second step. The second step is relegated to the iterations and stages of the framework. For details see A Fresh Look at Requirements and Requirements Elicitation in Complex Projects (PM Times, July 28, 2014)

SCHEDULING RESOURCES

If all active complex projects are identified within a portfolio the problems associated with resource scheduling are somewhat reduced. Unfortunately that situation rarely exists. Instead a number of projects that are defined and staffed within a single business unit are not part of any portfolio. While that may be true of a project it isn’t necessarily true of the resources that staff these “below the radar” projects.

IMPROVING PROCESS DESIGN

Complex projects don’t seem to follow any predictable process. Each project presents the team with a unique set of circumstances and challenges them to respond accordingly. That is why the ECPM Framework includes a continuous process and product improvement program. Figure 2 is the continuous process improvement program that has been integrated into the ECPM Framework.

Figure 2: The ECPM Framework continuous process improvement process

In time the organization will build a comprehensive collection of responses.

IMPROVING PRODUCT DESIGN

Figure 1 has also been integrated into the ECPM Framework but adapted to product improvement rather than process improvement. The Probative and Integrative Swim Lane process is the heart of that product improvement effort. It is unique to the ECPM Framework and will not be found in any other project management process.

IN SUMMARY

The ECPM Framework was designed with these challenges in mind. Most of the challenges are mitigated through ECPM Framework design features (Project governance, Measuring performance, Meaningfully involving clients, Structuring the project team, Eliciting requirements,

Scheduling constrained resources, Improving process design, Improving product design). Others are mitigated through the execution of the complex project.

How all of this happens requires a book length discussion and is out of scope for this article.

Avoid Ambiguity to Improve Performance

Written by George Pitagorsky on November 13, 2017. Posted in Articles. 17 Comments on Avoid Ambiguity to Improve Performance

Volatility, Uncertainty, Complexity and Ambiguity (VUCA) are alive and well in the world of projects.

These factors magnify the effects of one another to increase the risk of project failure and the need for increased management precision and capability.

Volatility (the frequency of change), uncertainty (the degree to which outcomes are known) and complexity (the number and kinds of relationships) are unavoidable. They are part of the fabric of every project, to one degree or another. While they can be moderated, they cannot be eliminated, mainly because they are driven by external factors beyond our control.

This article focuses on ambiguity and what to do to avoid it from making project performance more difficult than it needs to be. Ambiguity is a quality that we can control. Ambiguity is inexactness or vagueness; being open to multiple interpretations. It can be avoided by communicating clearly and precisely.

Example: ambiguous Target Date

Here is an example of ambiguity and how it effects performance:A policy decision is communicated to a division’s senior management with an effective date of September 1. The new policy requires changes to back-office application systems, procedures and to customer facing websites and mobile applications.

Ambiguity came into play because it was unclear as to when full compliance was required.

The policy decision was made and communicated to division management on August 15, as the division was gearing up for a long-planned initiative that required intensive work by the IT and staff and had a fixed deadline. The new directive was triggered by a regulatory decision. The regulators were usually satisfied with compliance within 90 days of the effective date (September 1), if it was requested and justified. Ambiguity resulted from the lack of clarity from the very top regarding when the policy would go into effect. Corporate executives said in their directive that compliance was required by September 1. Division management passed the directive down to business management and business management engaged IT.

IT and business operations management, aware that the regulation had been in the works since April, had obtained information from the regulators that compliance within 90 days was sufficient. The estimated work required to comply would take about a calendar month. The work was therefore planned to begin on September 15. Feedback to division senior management and from them to the corporate executive level went unanswered.

Was full implementation of the policy compliance required immediately on Sep 1? Or, was compliance within 90 days acceptable?

Without a definitive answer, operations and IT assumed that they better get ready with some evidence of compliance by September 1. They strongly suspected that if they waited, there would likely be no reprieve and if they didn’t wait, they’d probably be let off the hook when the executives realized that 90-day compliance was fine.

Advertisement
[widget id=”custom_html-68″]

They knew, as most project managers know, that getting a month’s worth of work done in less than half that time was highly unlikely. They needed to find a solution that would satisfy the demand in the available time and then buy the time to complete a more complete solution. In other words, there was a need for a scramble to get a minimally acceptable result done immediately. In this case, the team removed ambiguity by making a tactical decision. The executive level directive and the ambiguity it caused would result in a sub-optimal solution with high risk of failure and extra cost to move to the ultimate solution. The staff’s respect for their leadership was eroded. The schedule for the planned initiative was threatened because resources had to be diverted to the compliance project.

All this could have been avoided if the senior levels had responded quickly with clarification regarding the due date. Ambiguity disappears when people take the time and effort to communicate quickly and clearly.

Example: Ambiguous Role Definition

Here is another example.An employee with good project management and communication skills is assigned to a large complex program without clear understanding of her role. She thinks that she reports to the CEO who has given her over to the executive to whom the point person responsible for the project reports. No one clearly lays out their expectations of the role she is to play. Relatively comfortable with ambiguity, she takes on a project manager role, focusing on communication planning with the intention of helping the program manager succeed by promoting transparency and critiquing written reports and other communications.

The program manager, less used to and less comfortable with ambiguity, does not share information or engage in role negotiation. Dysfunction follows.

In this case the participants did not take it upon themselves to remove the ambiguity by acknowledging and addressing it. The new player made her life less ambiguous by pulling back. She stopped doing anything but what she was directed to do by the program manager. The program manager handled the ambiguity by ignoring the assigned person.

Practical Reality

“Are these examples real?” You might ask. Well, it seems that they happen more frequently than one would think.

People at every level make unfounded assumptions about the degree to which others understand what they say in the way they meant it to be understood. They fail to take the time to be explicit and complete in their communication. Others fail to ask for clarification or affirmation, maybe out of fear that they will be seen as slow-witted or because they think they understand.

Ways of avoiding ambiguity include active listening – making sure as the receiver of information you restate it in your own words and ask if you have it right. Ask questions to clarify anything that might seem fuzzy or ambiguous to you. As the sender, cultivate the facilitation skill of asking others to restate their understanding to make sure that there has been a meeting of the minds. Ask them if they have any questions or need any further information before they can move forward. In project work, putting things like objectives, role assignments and expectations in writing contributes to clarity and avoids ambiguity. It doesn’t have to be anything like a formal document, a simple confirmation email will work. As a leader, make sure those who work with you feel comfortable to raise questions and objections.

Recognize that the time and effort you take to avoid ambiguity will avoid rework, frustration and morale issues that lower productivity. The more volatile, uncertain and complex your situation, the more important it is to minimize ambiguity by communicating clearly and completely.

Note that uncertainty is not the same as ambiguity. Premature definition can be harmful. Complex situations like organizational change and the exact nature of a complex product must evolve. Evolution takes time and the ability to accept and work with uncertainty. One can be unambiguous (clear and explicit) about the fact that there is uncertainty.

The master project manager avoids ambiguity by communicating clearly, listening actively and ensuring that others mutually understand goals, roles and responsibilities.

The six headed uncertainty Hydra

Written by Sean Lowe on October 30, 2017. Posted in Articles. 8 Comments on The six headed uncertainty Hydra

Project closure can be bittersweet. A long and perhaps arduous endeavor has been completed, which is very satisfying.

The bitterness may come from the fact that you’ve already started your next assignment(s) and are in the throes of simultaneously conducting a post mortem and lessons learned. Many project managers, present company included … struggle, or used to struggle with the task of rapidly assembling a comprehensive project re-cap. The least of these tasks certainly not being recalling key project decisions, their exact timing, strategic implications, who sat at the decision table and the specifics of their decision making authority of each.

What if there were a guiding document that outlined parties and the specifics of their decision making authority as well as an associated chronological register of their key project decisions? Enter the Key Decision Matrix/Record! This tool can reside on two spreadsheet tabs, in a database, or via other automation available to the project team.

Why do I need this tool? Well, without it, you’re at Risk of not surviving a battle with the six-headed uncertainty Hydra. The six headed what, you ask? The six headed uncertainty Hydra is the crazed beast that charges at you during random project phases, especially closure, its multiple heads hungrily snapping at you for details that may or may not be buried in meeting minutes, multiple email correspondences, action item lists, etc. What decisions were made, and when? Why were these decisions made and what options were considered? What are the implications to adjacent projects and who was appointed to make these decisions?

Advertisement
[widget id=”custom_html-68″]

OK, let’s review the details of each section.

The Key Decision Matrix/Record is comprised of the following elements:

1. A list of Project Key Decision makers and the specifics of their decision making authority.

There are no rabbits in hats, here … and this is intended to be exactly as stated. From experience, you may encounter some resistance in documenting and formalizing this but it pays off in the end. Part of the reason for this is that for some reason, folks are somewhat hesitant to document specifics regarding decision making authority. This exercise also almost always promises to be eye opening for the PM, as they either end up having much more, or less “stated authority” than previously surmised.

2. An explanation if each Key Decision

This is the essential detail regarding the decision in question. Pay special attention to technical details if necessary as the more complete the explanation the better (multiple personnel may need to reference this document).

3. Specific dates and phases of occurrence

Making note of specific dates when key decisions were made lends historical significance to project milestones and will greatly assist in re-constructing timelines (if required) at a later date.

4. Why the Key decision was made and options considered, if any?

While each element of the decision record is important, capturing specifics regarding options considered, as well as why the final decision (option) was chosen will be particularly beneficial reference points.

5. Parties Privy to the decision

Number one, above, documents Project Key Decision makers and the specifics of their decision making authority. This section, however, specifically denotes which parties participated in and made each particular decision.

6. Decision Implications

The importance of this section is to document integration points, decision implications and how your project’s key decisions may affect neighboring projects.

Armed with this guiding document, facing and slaying the six headed uncertainty Hydra will require no more than referencing your Key Decision Matrix/Record. Furthermore, completing Post Mortem and Lessons Learned exercises will also be a snap.