First, I want to make sure you have the necessary knowledge of what a plan is. Most (and among them an astounding number of project managers) only remember the Gantt chart when they think of a project plan. You can get it using Microsoft Project. But this can rather be called a project schedule, which shows the time of implementation of various stages of the plan. However, we'll come back to that later.
Our plan should contain the following points:
- Purpose of the project
- Outcomes
- Quality criteria
- Resources
- Governance structure
- Milestones
- Expenses
- Constraints
- Risks
- Schedule
- Let's look at each item individually and see why they are so necessary and what we want to achieve in them.
Purpose of the project
So what do we want to create? The goal of the project is a combination of the reasons for the implementation of the project and the expected benefit from it. This segment of the plan can be implemented either by a profitable economic justification, or by familiarizing the target audience with the purpose of the project. For example, your business case may be written for approval by your organization's senior management.
Outcomes
There is a specific goal of the project. What do we need to create to achieve it? What will your finished project consist of? All of this should be clearly defined. For example, your goal might be to update your organization's IT infrastructure. Your end result will be a complete computer network, a new computer with all the necessary software on every desk.
Quality criteria
Now that we have the results, we need to specify the required level of quality. In the above example, we will have the result in the form of a complete computer network. However, we need to be sure that the network will actually be able to cope with the entire volume of traffic!
This means that our result must be of a certain quality and we need to specify a given level of quality. Here's what will point you to the success of the project:
- Clarity: Clear and crisp.
- Specification: that is, not "new computers", but "computers with 2Gb of RAM", etc.
- Achievability: Don't ask for the impossible.
- Relevance: Is the criterion related to the purpose of the project?
- Temporary control: sufficient time for execution. There is no point in expecting a year's worth of work in a week!
You should take some time and make this list together with the project participants. You should involve the end users, but do not forget about the business owners - do not promise everything without first estimating all the costs. Your project manager and the representative of those who will be doing the work are the main sources of all this.
Finally, you should stipulate in advance who has the last word regarding the quality of the results. Hopefully, your work on defining quality criteria will not imply disputes over quality (i.e. no disputes about quality, only quantity), but you should still make sure that everything goes according to schedule.
Resources
Now you know what results you need to get and what quality they should be. This means that you should now look for the resources that are necessary to achieve the goal. Resources include employees' time, certain knowledge or experience, money (such as buying equipment), and time (some tasks can be completed more quickly if more people solve them).
Governance structure
How will you handle the job? You need to describe the overall approach to the project. Who will make the decisions for the different workflows? For example, if you decide to make a significant purchase, who will decide who to buy from?
How will the progress of the project be shared? Between whom will it be divided? For example, you can schedule regular meetings with the team, but who should attend them? What level of information will you share? Who else needs to be aware of how often and at what level of detail? For example, you probably need to inform the project performer about the big picture of things weekly, while you will provide other managers with the necessary information more figuratively.
You will also need to approve your relationship with the project implementer regarding the monitoring of the progress of the project. Both of you have to specify how you will observe the progress and all the tasks set.
There is no right answer to how this should be done, as it will differ from project to project. Decide what you think about the size and complexity of the project, as well as the nature of the organization and the style of current management.
Milestones
Here you need to think in advance how you will divide the project into several stages. If it is not quite small, then you probably will not want to perform it in one fell swoop and at the same time check everything only at the very end. Instead, it is much better to break it down into several parts, where related tasks can be grouped together, with a checkpoint defined at the end of the phase. In the example about updating technologies, you, for example, can split the project into:
- Requirements Gathering
- Writing a formal proposal
- Application processing process
- Contract negotiations
- Commissioning
- Testing
You should define a checkpoint, thereby you will know about the completion of the stage. But there's also another plus to decomposing the work, but we'll dedicate you to that a little bit later.
Expenses
You've already explored the necessary resources. Now you need to understand how far you or the executor of the project can move away from the planned before it is worth sounding the alarm. For example, you can set the level of costs relative to finances in +/- 5%, and relative to time - in +/- 10%. You'll also want to set a cost level relative to quality – that is, how far you can afford to move away from established quality criteria.
It is not at all desirable for the project to depart far from the intended resources and quality. By setting the cost level, you can manage the project without having to constantly seek guidance from the project executor to continue the project. You should not underestimate these deviations, and you, of course, should avoid them, and therefore you should constantly monitor your progress. In this way, you can build your understanding of the project in the future.
Constraints
Here you should pay attention to the observance of a strict sequence of stages. For example, in the example mentioned above, you need to complete the requirements collection phase before you can complete the proposal. You need to start thinking about dependencies so that you and the project team can understand the impact of the changes on any part of the project.
These dependencies should include both external (that is, something over which you have no control) and internal (that is, those that you can manage) dependencies. For example, you probably need to know the exact number of employees in the organization, and this should be provided by the personnel department, and therefore, will be an external dependence.
Risks
What could possibly go wrong? What can happen and harm your project? Is there any way to avoid this or reduce the impact of the risks?
Schedule or Schedule
The schedule is information in the form of a Gantt chart - this is how most people imagine a project plan. To do this, you need to write down everything that needs to happen. The graph should include all dependencies, checkpoints, and surely resources. At this stage, the graph will be an overview of the entire project.
You should understand something about this schedule - it is erroneous.
Maybe it's loud, but it's very important to understand that you won't be able to create the perfect plan. You need to achieve the achievable. The schedule should include an overview in which the project is broken down into several parts. This is the second advantage of decomposition - once you break the project, you will be able to clearly plan the first stage and continue planning others later. But the further you plan, the more you'll make the plan blindly, and everything will depend on your faith and predictions. Do not try to be ultra-precise - let everything be fuzzy, use general numbers.
As you approach the end of each phase of the project, you'll be able to plan the next one. You can use the information and experience gained from the past stage, thereby you will feel more confident.
You should explain all this to the participants of your project! Often, the executor of the project, looking at the schedule, will imagine that everything is already prepared and known. You should dispel his dreams – explain that the initial stages are more accurate than the subsequent ones, and make sure that changes are expected as the project progresses.
The project executor will demand clarity and absolute execution dates from the start, but you should resist this pressure by explaining why you cannot provide such information. While you'll probably want to answer his questions (and, of course, the dates will be made up on the go), you should be realistic and understand what is possible and what is impossible to plan. Anything else can create problems for you, the project, and, of course, the executor.
Don't panic!
Despite the fact that you have a lot to fit into your plan, you should not worry, because you will have to work on it not only you.
You can't know everything you need to complete a plan, and you should expect that from yourself. I would suggest bringing in other people to help with the decisions, you can also involve people to make a schedule. The project team will do the work, so project team members will likely know better than you how to break the project into pieces and how long they will last. Use wisely the knowledge of the project team! This is the added benefit of involving them in the project, because they will help start the process and turn a group of people into a team.
No comments:
Post a Comment