Consistent Characteristics in Detail
1. Contains Guiding Processes
Who is the user of today's PM Methodology? It is clear that the stakeholder list includes Project Managers, Team Members, internal and external Customers, End Users, Project Management Offices, Sponsors, and Executive Managers. And within this list, each has some level of appropriate use. But the primary target for any methodology is those people who are performing work on the project, whether in managing it, making key decisions about it, or delivering the results.
And here is an irony: Even with the best methodologies, many target users tend to use it in full just the first 3-5 times. And the first several of those times, they are still learning it and not effectively applying it. After the fifth (or so) time they use it, most people have fully integrated the philosophy and approach. Thus the ideal PM Method should have approachable process explanations for beginners (and not overwhelming), yet be accessible enough for easy reference once each user, from new team members to Project Sponsor, has used it several times and has climbed the learning curve to Skills and Mastery (Competence).
2. Identifies Key Roles and Responsibilities
Too often we see methods that fail to identify the responsibilities of each role. Some fail to even include such crucial roles as Sponsor (or Project Executive), key managers who make prioritization and allocation decisions, and internal and external Customers or Clients. In reviewing project plans we continually point out the risk/threats these omissions present.
How do these stakeholders know what is expected of them? How much time it will take? Unless they are very experienced, they don't, and become a failure point. Thus a methodology must identify all the responsibilities each person filling one or more roles should sign up for. The responsibilities of an effective sponsor from one universal PM method are listed in Appendix A.
Do you have Sponsors who will "sign up" for such responsibilities? If not, who will perform them? And what are the consequences if some go missing? This shows why asapm co-founder Bill Duncan's OCiPM™ (Organizational Competence in Project Management, a standard against which to improve organizational PM effectiveness beyond maturity) is so important. You can see from this why a Competence-Based PM Method requires contextual competences, in addition to the technical ones, just as the USA National Competence Baseline prescribes.
3. Cites Competences needed by Role, by Process
To deliver on these responsibilities, it is clear that more than just the Project Manager must have PM Competence. But that is why asapm provides the PM CompModel, which identifies target Competences and Criteria (at varying levels) for all key stakeholders.
Thus the PM Method should relate the Competences needed, and the level required to complete each process or result. The consequence: You use this information (together with effective decision-making about priorities and allocation) to reduce time, cost and risk/threats, while increasing quality in every assignment in the project.
4. Provides useful Templates and Examples
About half of all people prefer to review process steps for project assignments that are new for them. That is why a process-oriented method is useful, at least until people no longer require a reference. The other half of all people tends to prefer an output or result-oriented template. Even with outputs such as computer code in an IT project, many of these people prefer to modify something that works even though someone else wrote it.
Templates for results are useful for this group of people. What makes them even more useful are two additions:
- Add annotation or explanations that reduce the need to use a separate process reference. These are especially useful if they can be shown or hidden at will, so they don't distract from the deliverable, when it is complete.
- Add Completed examples from your Enterprise, or even better, your own workgroup. Try as we may, when we have provided generic example sets, most people find them less useful because "they aren't like ours".
We've discovered an interesting aspect of that second point: For some interim results in your Enterprise, such as a Test Plan, 90% of it can be re-used in later projects. Thus these example templates can again reduce time, cost and risk/threats, while increasing quality in many parts of the project. Do you see a trend here?
5. Supplies Model Project Life Cycles
Too many Project Life Cycles begin too late, and end too early, to be useful. The actions taken (or failed to be taken) between Concept and formation of the project team determine most of the success or failure of today's projects. Estimates are made based on incomplete understanding of Scope, and a dollar amount or hours of effort is budgeted based on that information. Then too often, the team is held to that very preliminary estimate. Not only should the Life Cycle begin at the beginning, but the early scope discovery should also be traceable, and estimates revised, not held firm, at major Stage Gates or Milestones.
Similarly, too many Life Cycles (or Life Spans as our friend Max Wideman calls them) end when the team captures their Lessons Learned. Speaking of Max, see his excellent, in-depth article on Life Cycles at his website.[4] Obviously for the Enterprise, the true closure is when you verify Benefit Realization. In too many projects, that never happens, and even when it does there may be fewer benefits than promised, due to inadequate tracking or poor Change Control. Few people want to explain to Executive Management that the expected benefits fall short! Worse, the full benefit realization may require three months or three years after project closure, and no one remains on the team to perform the analysis - they were assigned to new projects long ago.
That is one set of considerations about Project Life Cycles. Here is another. Different groups in your enterprise need different Life Cycles, just because of the nature of their business. A Pharma Clinical Trials Life Cycle will differ from a Construction Engineering one. An Information Technology Life Cycle may have multiple variants, depending on the technologies applied, whether you buy or build (or outsource), or use classic versus agile methods. And networking is far different from Systems Development, and so on.
Within the Life Cycle, the Work Breakdown Structures (WBS) must vary in depth and breadth based on the size of the project. Small, Medium, Large, and Too-Large projects (Too Large projects tend to cost more per delivered Scope-point, and fail much more frequently) each require a different number of phases, and different numbers of levels of detail within each phase. And to use a Medium Life Cycle WBS on a Small Project causes far too much overhead in the project.
Sound like chaos? There are solutions. Even with multiple different Life Cycles, savvy Project Oriented Enterprises establish common "roll-up" points. These are usually based on similar or identical Major Milestones or Gates throughout all their Life Cycles. This consistency where needed, and adaptability where required approach works for almost all Enterprises, and any Universal PM Method must support it.
6. Offers Audit Checklists
Assuring proper process, Governance trails and other verifications result from a consistently applied PM Method. But how can you assure that you are using yours effectively? Especially important: How can you perform this assurance pro-actively, while the work is in process versus in autopsy mode, when it is too late to correct omissions?
An effective PM Method should provide process, compliance and result audit checklists. Not just yes/no quantitative ones (Does the Project have a Business Case and Charter or Brief?), but qualitative ones that specify the criteria for adequate ones. This approach not only helps guide the team to better results, we also use it to measure progress of implementation for new methodology users. The information, in some cases, is useful as part of Department Manager's Project Improvement Performance Reviews.
7. Is customizable by Enterprises and Teams
Customizability is important for a number of reasons, including the obvious: Enterprises have different requirements. We find that if an Enterprise does not feel the need to make even a minimum amount of change, they will probably not succeed with the method. This makes a good early assessment of success. And some want to change too much; those Enterprises often fail, as well.
There is another reason for Customizing: The Enterprise that does the right amount of customizing (typically around 10-15% if it is the appropriate PM Method for them) builds a sense of ownership that is essential for integration and adoption as part of the Enterprise culture. That Change Management process only works if all the right people participate in that customization - not if it is merely done for everyone by the Project Management Office.
Related to customizing, see our PM Methods Improvement Plan.[5] It is a methodology for successfully implementing a PM Methodology. Yes, we understand that is a bit recursive; but practical use is the best way to evaluate any methodology. The document explains more about the process and benefits of engaging PM practitioners in adapting the methods they will use. PM Methods Improvement Plan has been used to improve PM Methods by hundreds of companies over the last 20 years.
This need for customization has always existed, but in "the old days" when the vendor delivered eight 3-inch three-ring binders it was more difficult than it is today. Still, even with web pages and custom forms in PM Software, customization is not easy. The current popular solutions include either a high-end content management system (hard to learn, hard to use, but very powerful), or a Wiki based approach (increasingly popular, but may require external hosting and a constant network connection). This will continue to be an area of constant change.
8. Is Tool-neutral
Tool-neutral means you don't have to buy another product to use it. For example, it has been popular in the past to just add process explanations to PM Tools such as Microsoft Project. That's fine, for those who already have it (and who can do more than move Gantt bars around until it looks good enough for Management approval). But what about everyone else, especially now that most companies have 50-70% of their staff involved with projects?
Many serious Project-Oriented Enterprises have already invested in industrial strength PM Software. As well, some organizations use non-Windows software (gasp!). We are seeing a broad movement away from proprietary single source solutions, and toward Open Source options. Thus this requirement adds complexity, because any PM Method should use the tools an Enterprise has invested in, but not require additional ones, or additional copies. This is driving us towards web-based solutions.
9. Offers a Range of Rigor
A project to update your department procedures does not require the level of rigor needed by a project to fulfill a contract commitment. A small project does not need as much ceremony and supporting documentation as a medium one. A very large project may have significant demands for interdepartmental or inter-organization and international coordination, while a medium project may involve a half dozen people within the same office.
A PM Method must provide guidance for the right level of rigor, documentation, review cycles, and approvals - and identify the cases where variances from that guidance are wiser than blind application.
Of course, some people avoid all rigor, as a matter of personal style. Even those people can appreciate appropriate rigor when they see how the rigor helps them. Conversely, methods that add rigor but fail to help the people doing the work will continue to fail.
10. Saves more Effort and Time than it Costs
This characteristic is the flip side of the above item on rigor. Any new method will require more time at first. Training, coaching, monitoring, establishing new baseline and ongoing performance measures all take time. There is also the issue of the Learning Curve. But after the "third time's a charm" use, any effective PM Method must clearly save more time than it requires. And measurably so. This is the greatest place where we have seen Enterprises fail in improving PM Methods: even when they achieve huge savings, they cannot prove it.
Or, they cannot separate out the benefits of each of several components implemented concurrently, to see, for example, that the new chosen tool requires too much effort for the value of the information it provides, thus wiping out much of the Methods gain. Or, the Enterprise fails to establish the new Policies, Roles and Responsibilities that are the prerequisite to any lasting change. The Methods can't do it all.
4. See Max
Wideman's excellent article on Life Cycles at: www.maxwideman.com/papers/plc-models/intro.htm.
5. PM Methods Improvement Plan describes a methodology for
PM Methods improvement. See it at www.ProjectExperts.com/articles/PM_MIP.pdf.
|
Moving
Target or Consistent Characteristics?
