Abstract
The main tool for the project manager to cut through the complexity of a project should be the methodology; however, often the methodology is perceived more as a burden than a real help. Project managers see it as a waste of time to write documents they feel have no added value to them and that the methodology is only a tool of the project management office (PMO) used to monitor their work.
This paper covers the crucial points that make a methodology useful. It is directed to members of PMOs who can directly influence a methodology and also to project managers to give them hints on how they can get the most out of an existing methodology.
The focus is on the following areas:
- To make the methodology scalable and flexible, so that it can be adjusted to the size and character of the project.
- To limit the number and size of the documents on what adds value and what is required to be compliant.
- To use more open documents that do not have to be signed or to use tools instead of documents
- To create the documents and templates with the stakeholders in mind
- To give more responsibility to the project manager when it comes to project selection
- How to “sell” a methodology to the users
- How the project manager can make the best of an existing methodology
Why Methodologies are Unpopular
While project management methodologies should be intended to be a means for both the project managers and the stakeholders to facilitate the communication and control within a project, the perception from both sides is, in many cases, rather negative. The reasons are on the one hand in the structures of the methodologies; on the other hand, in the ways they are implemented.
The Structure
Many traditional methodologies are rather rigid and do not leave a lot of room for configuration. A project manager has to create a number of documents in exactly the ways the templates are structured. If a chapter is perceived as irrelevant, the reason must be stated in the document. It might be suspected, that these methodologies were designed by PMO employees, who have a somewhat academic understanding of project management, but have rarely applied it in real life. Because of that, these methodologies contain all the necessary documents and tools, but ignore the specific needs of the industry or the stakeholders the project manager has to deal with.
The Implementation
It appears that some PMOs assume that project managers simply know how to deal with a methodology, because they are Project Management Professional (PMP)® credential holders. So, the methodology might be simply dropped on the project manager with no or only brief training, with the assumption that by handing out a list with the documents, as well as prefilled example templates, the project managers can deal with it. To be fair, long trainings are also not very welcome by project managers, because they assume (mostly correctly) that they will have to do them in addition to their on-going project work.
The Perception
Because of the ways the methodologies are sometimes structured and implemented, project managers perceive them rather negatively. They do not see the value, as they feel they are fine with the way they have been managing projects until now. They primarily realize how much more time they will have to invest writing the documents but do not feel any additional benefit; hence, they perceive the methodology as a tool of the PMO to control them and the methodology as a tool for the PMO rather than for them.
Furthermore, other stakeholders can perceive the methodology as negative. On the one hand, the project managers have the responsibility to explain to their customers why these documents have to be written and what the benefit for the customer is. However, as the project managers are not convinced themselves, they are not able or willing to “sell” the methodology; rather, they send messages like “It has to be done.” And, on the other hand, if the methodology is not written with the stakeholders in mind, the documents the stakeholders have to review can be so complex that they either do not review them or they get lost in the process.
The Result
In the end, the possible result is that the project managers fill in all the necessary documents in a way that costs them the least amount of effort—just to get it over with. Because of this, the value that they can draw out of the methodology is almost zero. The stakeholders are confused about the content of these documents, which results in misunderstandings and conflicts. What remains are frustrated project managers who do unnecessary work, which creates more damage than value.
How to Improve a Methodology
Focus on the Purpose
To improve a methodology it is necessary to define its purpose and adjust the methodology afterward accordingly. We can split the purpose into three main points:
- A tool for the project manager to control the project in all its dimensions
- A means of communication between the project team and the stakeholders
- A control instrument for the PMO to ensure that crucial processes and regulations are respected
While the control point surely has its justification, in many cases PMOs only focus on the control and forget the first two points completely or assume they are automatically included when creating a methodology. So, improving a methodology means mostly shifting the weight from the control aspect to enabling project managers and enhancing communication within the project.
Six Concepts
Described below are six concepts, which help with this weight shifting:
Scalability
The sizes of projects vary widely — from a multiyear billion dollar program down to a 1-month-long website mini-project—all are possible. So, if projects vary so massively in size, why shouldn't the methodology structure also be scalable? For each project size there should be the respective solution on the methodology side, which can be accomplished with three measures:
Size levels
By introducing different size levels in the methodology (e.g., small, medium, and large) a foundation can be built for the scalability. A clear definition of which documents/deliverables are required per size level helps tremendously to adjust the administrative work for the project managers. In addition, a description of how the size of a project can be specified is required. Is a project that is very expensive due to, for example, high licensing costs, but it only takes two months to finish, whether it be small or large? This illustrates that it is quite difficult to define rigid brackets. A better way would be, for example, to describe the characteristics of the different sizes of brackets, and then let the project managers (based on these descriptions) make a proposal, which the PMO will validate.
Document status
While for some documents there is a very clear need for a certain size level that cannot be argued with (e.g., project charter on every level), for many documents, the need to create them depends on many other criteria, such as the risks involved or the tasks’ complexity. This is why it helps to classify documents in different statuses (e.g., mandatory, optional, or not needed). This way it can be very clearly signalled to the project managers, which documents they have to create, which documents they should consider if they apply to a specific project, and which documents will not be perceived as necessary at the specific size level.
Specific templates
The last measure that can be taken is to create different versions of key documents. A project charter for a large project will look, for example, substantially different than a charter for a tiny one. To offer different templates that take these changes into account, will enable the project managers to create the documents faster and ensures that all needed information is contained in a short and concise manner. There is also the option to consolidate different documents into one, so that, for example, a charter template for a small size project already includes the sections for requirement specification, communication plan, and stakeholder management, whereas for a large project, separate templates for all these areas would be provided.
Flexibility
With implementing the scalability concept, letting project managers choose the sizes of their projects and especially by making documents optional, certain flexibility exists already. But the templates themselves are still rigid and may contain instructions, such as “All sections have to be filled in. If some section is not applicable, a justification must be written as to why this does not apply.” Once again, such lines do more damage than they help, as they clearly state that there is lack of trust against the project manager and, in addition, it makes the final documents rather difficult to read.
To improve this there needs to be a change in the perception of the templates. A template should not be there to force project managers to write a document in a certain way; rather, it should serve as a guide.
There surely might be sections of a template that must be filled. They should be clearly marked, but should be the exception and, once again, the PMO should have a very clear reasoning, why they are mandatory and they should also be willing and able to communicate that.
All other sections should be optional, which means that project managers have the choice to use them or delete them without having to give any written justification as to why they are doing so. This also enables the PMO to add more sections into the template, simply as a suggestion for the project managers what else could be covered in these documents if there is a need.
Value and Requirements
One of the most important criteria to make a methodology positively perceived is that nobody should ever be able to question why a document exists. Or, in other words, the PMO should have a very good argument prepared for each document and why its creation brings value. This means asking the following questions for each document:
- Does this document add any value in managing the project?
- How does the document support project managers in doing their work?
- What value does the creation of the document add to the PMO?
- Is the document required by any external authority (e.g., the FDA)?
If no good reasons can be found, the document should be removed or flagged as optional. If value can only be found in parts of documents, only these parts should be kept. Sometimes it also helps to merge fragments of multiple documents into one.
Tools and Live Documents
It is quite common that methodologies contain a risk register document, which will need an approval signature when completed. This is the perfect example of a useless, work-generating paper pile. Because it symbolizes that this is a one-time task and once the signature is gathered, this document is done and can be ignored for the rest of the project.
An easy way to improve this is by deleting the signature section and to label this as a “live document.” This should be done with all documents that act more as a tool than as a means to reaching an agreement. These questions should be asked: “What is the value of the signatures?” and “What do the signatures mean?” In most cases, the signatures are needed when they symbolize an agreement between two parties on what has to be achieved and how. But it is quite common that signatures also simply serve as a way to confirm that the document was received or read. This (mis-) usage of signatures should be questioned and, if possible, eliminated.
But let's take it a step further. Does it make sense to create a risk register with a word processor? Would it not be much more productive for project managers if they would have a tool, maybe even a collaborative tool at hand, where the whole team could enter and review risks on a continuous basis? There are lots of tools like these on the market today for a multitude of devices.
To conclude: Only documents that serve as an agreement between two or more parties should be signed or even belong on paper. Introducing “Live documents” or even switching to tools encourages and enables project managers to do critical evaluation processes on a continuous basis throughout the whole project.
Customer Centricity
Project managers and specialists, such as IT employees, all speak their own language with a very specific terminology. When the documents the customer has to agree with are now written in a combination of these languages: “The UAT has the scope of the UI and will be conducted in three iterations.....” the reaction of the customer will be a mixture of confusion, ignorance, and anger. To make matters worse, such documents can be quite lengthy. With a little push, an agreement can be enforced, but it is worthless, as neither the true intent of the customer is clear nor does the customer understand what the project team is trying to accomplish.
To mitigate this risk, the documents have to be improved in length and language, but most of all, they have to be identified. By grouping documents in clearly project internal documents and customer facing documents, a crucial step has been taken.
All documents the customer will have contact with, will need to be written with the customer in mind. The following questions should be asked:
Which amount is the customer used to reading?
The amount of material people feel comfortable reading depends on their functions. A scientist might be used to going through huge stacks of papers, whereas a senior manager is used to getting the key issues presented in a condensed abstract. Although the scientist might refuse the one-page document and deem it as not detailed enough to be trustworthy, the senior manager may simply not be willing to read the lengthy document.
What “language” or terminology does the customer understand?
Only terminology the customer understands should be used. Abbreviations should also be omitted. But this topic goes much further and should take into consideration which format of communication the customer is usually exposed to. While a scientist might rely mostly on numbers, graphs, and a lot of text, a marketing person might be used to colours, shapes, and icons. It might even make sense to develop completely different templates for certain customers!
What really matters to the customer and which sections should be better covered in a project internal document?
Documents, which are directed to the customer, should only contain information that is relevant to the customer. Everything else wastes the time of the customer and might lead to additional questions and review rounds.
Empowering Project Managers
Companies use a lot of effort to find the perfect project managers and making sure they are certified. When they find them, they treat them like they have no clue how to do their job and tell them, step by step, what they have to do, which documents to write and how, and requesting that each document is signed to ensure that the project manager has written it. Isn't this ironic? How does a project manager feel about such treatment? Motivated? Empowered? Probably not!
If project managers are to use their full potential, they must feel empowered and must be able to make their own decisions, with the clear understanding, that they are also accountable for them. This theme runs through this whole document: Deciding the size of the project, which documents to choose, which sections in the document to use, and to exchange signed documents with tools without signatures — all these are steps used to empower project managers and to give them the chance to configure the methodology in a way that works best for them! It is probably the most important step in making out of a methodology-obeying project manager a motivated one, who will go the extra mile for a success!
How to “Sell” a Methodology
Only Halfway Down the Road
Even if all of the above has been done, only half of the work is done; because if the improved methodology is not rolled out in a proper manner, it will just be considered more of the same and dealt with the same way as its predecessor.
The “What is in it for me?” Principle
Whenever anything is rolled out to the end-user, the question he or she always asks is “What is in it for me?” It is this fundamental question that has to be kept in mind when creating any communication, documentation, and trainings. If a believable, honest, and open manner to project managers can be communicated and demonstrated, and that this new methodology was created with them in mind, the chances to reach a buy-in increase massively.
Support versus Police
Project managers are still accustomed to a PMO acting as a police organization and the methodology is the means to enforcing and controlling the laws. It is extremely crucial that, in addition to the new methodology, this image of the PMO and the methodology has to be changed. The new image should be a PMO that is there to support and consult the project managers and a methodology that was created to give the project managers a proper tool in their hands to make their work easier and more effective.
Proper Training and Documentation
Last, but not least, the methodology must be properly trained. This training should have two aspects: the effective training and the sale component.
Training
In many cases, the training of a methodology simply covers the structure of the phases, the milestones, and the names of the documents, followed by a lesson in what must be done, what is mandatory, and what will be expected from the project managers.
A much better approach is to really go into the depth of each document, explain how project managers can get the most use out of this document, show them some tips and tricks, and let them participate in a case study so they can try it out themselves. To cover this in an average size methodology the training should be at least two days long.
Sale
It is essential to explain to the project managers all aspects of how the methodology was improved and that the weaknesses of the old methodology are admittedly brutally honest. Depending on how much improvement was needed and how hated a methodology was, there really needs to be a completely fresh start to get the buy-in. What also helps is to encourage project managers to review the new methodology and provide feedback. This intensifies the understanding that this new phase is more a collaborative than a top-down approach.
Documentation
The whole methodology should be properly documented, so that helpful references are available after the training is completed. It is also important to ensure a way to train the newly on boarded, be it through regular trainings and/or e-learning.
Making the Best of What There Is
Exploring the Possibilities
Until now, this paper has covered only the situation of when a PMO is willing to change or, better, improve a methodology. But what can project managers do if they are stuck with an existing methodology?
First of all, they can explore, based on this document, what is possible. Some concepts might be already feasible, even if not specifically explained or encouraged by the PMO. It makes sense to also talk to the PMO, to make proposals, and to ask if things could be done differently.
Finding a Helping Hand
The good part of being a project manager is that there are usually many in a company; so, there is already a lot of hands-on experience about how to get the most out of the current methodology. Accessing this pool of knowledge might be even more helpful than any official methodology guideline.
Documenting versus Using
And finally, project managers should never let the quality of their work suffer simply because of a not so useful methodology. As an example, I refer back to the Risk Register scenario. In case a signed paper risk register is mandatory, then this could be done with just the major 10 risks to document them and communicate them with the stakeholders. In addition, a tool of personal choice should be used to manage risks on a continuous basis. This way both parts—the document and the tool—have a clear purpose and no time is wasted.
Conclusion
Improving a methodology can make a huge difference to the productivity and motivation of project managers. The key is that the PMO needs to change from a police unit into a support organization, making the methodology as lean and flexible as possible, empowering the project managers to make full use of all the new options, and never losing sight of the stakeholders. A clear and honest communication and training, where the “What's in it for me?” message is clearly pointed out is the key to getting the buy-in of the project managers.
