Preparation of documents (standards, regulations, forms, templates) is often a very boring stage in almost any business. But if we are talking about making a really working document-tool - understandable and clear, which can improve the lives of many employees - then such work is personally to my liking. In the process of creating a project management methodology, such documents are necessary at the very beginning, but for many it is not clear what exactly needs to be described. After all, it is necessary, on the one hand, to regulate the entire range of processes, on the other hand, it is enough to detail each. Where to start and how to do it quickly?
Project Lifecycle
As a rule, the beginning of the beginnings of any methodology is the description of the life cycle. The life cycle is a set of stages through which a project must go from the moment of initiation to its completion. All projects should somehow begin, somehow plan, when performing work, communications, reporting and decision-making should be established, and after receiving all the necessary products and services, the project should be closed. These are the main phases that are always described and included in the project management regulations. Their beginning and completion are associated with the preparation of documents, they are guided for regular meetings and many other management functions are performed. When you undertake to create a methodology, your first document will describe key milestones that will give an understanding of the project position, lay down the main documents and actions for management.
For example, PMBok gives a lifecycle diagram as follows:
That is, everything is very simple – describe the life cycle.
Even now, I hear a few indignant voices. After all, project to project is different, and different projects may require different documents and different actions... For example, the simplest projects do not require careful study and lengthy coordination of the launch. If we are talking about a complex, lengthy and expensive project, then, on the contrary, its start should be well checked, investigated and agreed with many people. How to be and what exactly to describe?
Levels of management and levels of methodology
Of course, the detail of the description, the composition of the documents and the requirements for their preparation, the mandatory participants of the project and the level of their authority - all this is different for projects of different scale or degree of complexity.
I am deeply convinced that the methodology should be separated for different projects and provide different levels of management. Therefore, before describing the life cycle of a project, you need to understand for which project you will describe it. The start of the methodology can be made either on the most common projects of the organization or on the most large-scale and expensive ones. In both cases, you will start with the main thing: in the first, you will cover most of your projects with regulations, and in the second, you will ensure order in the most significant segment for top management.
What documents are we talking about? The main actions that need to be described, and the main documents are not so many:
One of the most important and difficult questions, in my opinion, is to determine what a "project" is for a company, and what are the levels of these activities. For projects with different levels of risk, complexity of execution or composition of participants, different documents or separate procedures for their preparation may be necessary. And for "not projects", simple assignments or tasks, it is not worth wasting time on bureaucratic costs. So the solution of this issue will greatly affect the preparation of your methodology. Often with the concept of "project" is associated:
• what is expensive;
• what is long;
• something that is not clear how to do;
• something that uses scarce resources;
• what management needs.
But this is not a guarantee of great complexity of execution.
Excel-Pmt. Also does not provide an answer to this question. The phrase "a temporary venture to produce unique results" does not reveal the essence and sometimes only interferes with understanding. At what point is a separately appointed manager needed, when the performance of a particular task should be covered in reporting to management, in which cases staff training and monitoring of the progress of work in a software product are required? In addition, if there is no understanding of how complex or important the project is, then there are many related problems that will have to be solved "manually". For example:
- complex projects are managed as "simple" or vice versa;
- the complexity of the work may not take into account the necessary competencies of the manager or the level of his authority;
- there is no justification for the requirement of "expensive" resources;
- there is no justification of motivation /financial motivation;
- it is difficult to emphasize the importance of decision-making, a complex project may not receive due attention.
All these questions lead to the need to create a methodology for determining the types of projects. I called such a document "a method of determining complexity."
Methodology for determining the complexity of projects
The complexity of the project should be based on the complexity of management and the requirements for the competencies of the staff. Therefore, when creating the methodology, I was guided by ISO 9001 "Guidelines for assessing the competence of project managers" and used the method of grouping according to several criteria. ISO allowed me to identify criteria for understanding the complexity of the work, and the method formed a clear algorithm for using these criteria. To apply the method, it is necessary to formulate signs that emphasize the complexity of the project. Each feature (criterion) is assigned a weight and a rating system. Weight determines the priority of the criterion, focuses on a particular complexity, and the evaluation system allows you to digitize design work on the basis.
Example of a system of criteria, their estimates and weights:
Projects are evaluated according to each criterion, multiplied by its weight and added up the result. If the resulting value is greater than the limit for "project work", then the task is performed within the project, and if not, then the task will not require complex processes of initiation, planning and control. With this approach, you will have an understanding of how many of your tasks you need to actually manage projects, how many project managers will be involved, what kind of workload the project office and project committee will have, etc.
The threshold value can be determined by using your knowledge of past projects in the company. Based on the history of execution, you can immediately "evaluate" the work performed - it was a project or for these tasks it was not necessary to complicate the management processes. Choose "very complex", "complex", "typical" projects and not projects at all. And based on this knowledge, you will form not only the threshold values of the method, but also the weights for your criteria.
An example of using such a system that sets management standards for projects of different levels:
How to simplify management: a real-life example
When I moved to the position of head of the project office at Excel-pmt Consulting, one of the first documents I had to create was a methodology for determining complexity. It turned out that the task-rich development plan of the organization accumulated quite a lot of small tasks that cannot and should not be performed as projects. At the same time, the company's management did not want to lose them from the field of its control. With the help of the methodology, we solved this contradiction quite simply. We have divided all activities for the development of the company into three types:
• Projects
• Strategic initiatives
• Business Process Description Projects
An example of evaluating projects by the level of complexity used in excel-pmt Consulting
At the same time, the latter type was not the responsibility of the project office. The work on the preparation of regulations is important, but not critical for business, so its strict and frequent control irritates both performers and management, and the Project Office feels unnecessary.
With regard to projects and strategic initiatives, we have separated their management in terms of documents and processes. For example, strategic initiatives are initiated more quickly, do not require the creation of a full Charter and go through a simple path of harmonization. In addition, during the implementation of the initiative, no intervention of the Project Committee is required to agree on the changes to be included and resolve issues. This makes them easier and more flexible to manage content. As for projects, the level of complexity and importance of their results requires more careful study, stricter rules for coordinating changes and a different composition of decision-makers.
When the term "project" was defined, the preparation of the company's project management regulations was not difficult, I just had to collect the requirements for supporting the life cycle of the two types of activities. Defining the life cycle for a valid "PROJECT" is what is needed to start the methodology. Such work will dot all the i's: determine what you will manage, how you will do it and what documents to use.
I note that the methodology should take into account the level of automation. So after the first step, creating a methodology, consider choosing a reliable tool to support your new processes. Long stages of work on projects can be greatly reduced and even not used at all if you have a software product that allows you to automate the creation of documents, collect and provide reports, search for information and analyze data. And convenient work and clearly formulated rules will become a really reliable start to system management.
No comments:
Post a Comment