Guidance on managing implementation projects based on MS Project 2000 and PMI recommendations

 

 

What is this work about?
31% of projects fail
53% of projects are completed with an average budget overrun of 1.9 times
only 16% of projects meet the deadline and budget
Data from the consulting company Standish Group

This article answers the following questions:

How do I make my projects manageable?
How to estimate the real cost of the project?
How to assess the real risk of the project?
How to effectively use MS Project 2000 in projects?
Managers are always concerned about the problems of controlling the activities of the unit, improving forecasting, completing the task within the budget and deadlines, reducing risks.

As a means of addressing these problems, business methodologies from a project perspective have been developed. Various automation tools have been developed for project management techniques.

In this paper, we will consider the methodology of project management in a group of 2 to 10 people. This group size was chosen because this is the typical size of a working group in an average Russian company. MS Project 2000 is used as a tool to automate project management.

Our methodology is based on the analysis of an end-to-end example of a project for the implementation of a certain software product. The implementation project was chosen as an example due to the fact that we have extensive experience in conducting projects of this type. Any organization has to deal with the implementation of software (software), so the particular features of conducting such projects can be useful to everyone. The very methodology of project management is not focused on a specific type of project and can be used for other types of work.

Software implementation projects are also interesting because, as a rule, they are very risky. The probability of completing the project, meeting the budget and deadlines according to world statistics from Standish Group does not exceed 31%. Therefore, we will be able to consider in sufficient detail the issues of risk management in small projects.

 

In such sections, I will cite the objections made by the experts and comment on them myself.

Remark 1. "It's not a technique yet – just some tips for scheduling and discussing common problems. Move in the right direction, but the initial steps. In general, it is a pleasant impression.

That's right, the work is devoted to the initial training of project methods and the discussion of subtle places useful and experts. In my experience, I have noticed that the most easily digested material is in the form of living examples, rather than super-detailed instructions. In addition, I deliberately missed some points of project management, on which problems usually do not arise, and vice versa, I dwelled in great detail on the particulars that can be the causes of serious difficulties. To be formally accurate, these are rather useful guidelines, rather than a full-fledged methodology like PMBOK. I deliberately "force" the manager to make mistakes in the course of the example, because it is the consequences of errors that make it easier to remember the necessary requirements for project management. In addition, managers make certain mistakes in management almost always and they are more interested in how to correct the mistake, and not only how to do it before the start of work.

Remark 2. Is there something you don't see the definition of a project, what do you mean by a project?

It's a trap question. According to PMBOK, "A project is an event that has a unique result and is limited by time. What does not fall under this definition is operational activity." The subtlety is this, even operational activities can be considered as a project, for example, a quarterly work plan for the production workshop of serial products. Time limit? Yes. Is the result unique? There is, because the result is unique in the temporal characteristic of its achievement. Is there any benefit from considering operational activities in the form of a project? There is, using this approach, you can implement project planning tools and achieve greater manageability of quarterly work.

Introduction. A Brief Theory of Project Management
As already mentioned, we will consider the general methodology for managing small projects, therefore, first of all, we will make a brief overview of the elements of the theory of project management. This section is devoted to an overview of the theory of project management.

Literature

Here is a list of references on which our methodology is based. Next, we will refer to these documents and publications.

ISO 9000 (standards governing project activities and quality maintenance)
PMI Standards. A guide to the project management body of knowledge (a set of full-fledged methods for project management )
SEI. The Capability Maturity Model (standard governing the requirements for software projects)
V. Kupershtein. Modern information technologies in office work and management (description of work with MS Project from the user's point of view)
Standard project progress
Guidance on managing implementation projects based on MS Project 2000 and PMI recommendations

The standard approach to project management consists of the following stages:

Setting the task (fixing the goal of the project).
Planning (development of a plan and budget).
Control and analysis of execution, correction of plans.
Project closure on formal procedure and analysis of statistics.
In many cases, project management is understood only as planning, and documented goal setting and project tracking management are usually overlooked. It is not surprising that, according to statistics, such projects, as a rule, significantly exceed the planned budget and deadlines, and also achieve not the results that were planned.

 

 

Remark 1. Not only that's the point, not everyone is limited to planning.

That's right, there are more reasons for the possible crisis, about them below.

Planning technique

Guidance on managing implementation projects based on MS Project 2000 and PMI recommendations

The planning phase is one of the most important. At this point, you define the tasks, budget, and timelines of the project. Quite often, planning is understood only as scheduling work, losing sight of resource management, budgeting, etc.

A complete planning technique includes the following stages:

Define project goals and describe them. Quite often, projects start without a clear goal.
Definition of technological stages. For the project, an implementation technology should be chosen that determines the stages of project development. One of the typical planning mistakes is the inconsistency of the plan with the technological cycle.

For technological stages, you need to define a list of tasks, specify their relationships (sequence) and the predicted duration (depending on the assigned resources).

The resources allocated to the project should be agreed upon. It should be noted that all resources of the company should be distributed centrally. Quite often, there is a scheduling error due to the fact that some scarce resources are used simultaneously in two different projects at the same time.
The schedule of work in systems such as MS Project is obtained automatically if tasks and resources are defined.

If you determine the cost of resources, the budget can also be obtained automatically. One of the typical mistakes is that the budget is assigned without paying attention to the projected cost of the project.
The written assignment, budget and work schedule form a formal document "Project Plan". Quite often, before the start of the project, some of these documents are missing, the consequences of this we will consider below.
 

Remark 1. The work schedule requires mandatory resource management. The allocation of resources should correspond to the already drawn up schedule of work – first based on the roles.

This is true, but many are starting to use scheduling systems simply to schedule work without specifying resources or instead of resources by specifying those responsible for tasks (not the same thing). From the PMI point of view, this is criminal, but from the point of view of planning a small project, it is sometimes convenient. Therefore, I deliberately do not focus on resource management in the first steps of the example.

Remark 2. The project plan includes other sections – for example, management regulations, document management, risk analysis, etc. The project plan requires a large number of mandatory formal documents.

It's like that. But we consider small projects where the development of individual documents can be compared with the complexity of the project itself, so I deliberately go for simplifications.

Remark 3. Scheduling is an iterative process – the initial schedule is repeatedly adjusted with resource reassignments if the deadlines are not satisfactory. Already at this stage, a risk analysis is necessary

As I have already noted, this work is based on the consideration of an example where the manager makes mistakes in the course of planning. The consequences of the absence in terms of anti-risk measures we will see below.

 

Typical planning methods. Budget and material resources
We will consider our recommendations on an end-to-end example of a project for the adaptation and implementation of a certain software product. Part I will be devoted to the procedure for launching the project. We will consider planning methods, methods of budgeting using human and material resources. Along the way, we will make small typical mistakes, the consequences and methods of eliminating which we will consider in the next part.

Problem Statement

The project should begin with the formulation of the goal. In this case, the goal should be recorded in writing in the form of measurable indicators.

The Problem Statement document should answer the following questions:

• In what time frame should the goal be achieved?
• What conditions for achieving the goal are available (budget, resources, technology)?
• How to measure the achievement of the goal?
• How are the key responsibilities in the project distributed (who is responsible for what)?
• Does the sponsor agree with the definition of the goal and the conditions for achieving it?

 

In our example, the goal of the project is to adapt and implement a certain document management system. In our case, the task was written, only the way to measure that the goal had been achieved was not determined; we will see the consequences of this later.

List of stages

Let's go directly to our example. The manager received a task setting for the adaptation and implementation of a certain Web Work Flow product. The manager starts Microsoft Project 2000 and starts creating a computer model of the project. As you can see, the manager proceeded to this without fully agreeing on the tasks and goals of the project, this organizational error will lead to consequences, which we will consider below.

After starting MS Project 2000, the manager immediately sees a list for entering tasks with a graphical scheme of the project (Gantt Chart). On the left are the list view radio buttons.

At the very beginning of the plan, the manager enters a list of stages corresponding to the implementation technology.

Guidance on managing implementation projects based on MS Project 2000 and PMI recommendations

A note to advanced users. As you can see, the appearance of MS Project 2000 has not undergone significant changes compared to MS Project 98. Of the new products, we can note the new view of the Network Diagram project, which replaced the Pert Chart. The new view allows you to view projects as a graphical diagram, as previously in PERT charts, while adding the ability to work with hierarchical tasks, as in Gantt charts.

Tip. Enable summary Task in order to see summarized statistics on the project (total duration, labor intensity, cost, etc.).

Task list

Focusing on the written task, the manager assigned tasks for all technological stages.

Remark. "There should be standard fragments (subprojects) – the corporate standard for performing standard stages. Testing is unlikely to be much different for different tasks and there is nothing for the manager to reinvent the wheel every time."

I can only agree. Project patterns are required. The question is how well they are made. Abstractly or from successful practice? The above is also a template consisting in the use of standard technological steps. This template will allow you to get uniform statistics on the stages of all projects, but as we will see, it suffers from a drawback precisely because of the lack of allocation of subprojects.

Guidance on managing implementation projects based on MS Project 2000 and PMI recommendations

Task duration

After analyzing the task, the manager made his own idea of their labor intensity and entered this information. At the same time, the manager did not proceed not so much from the qualifications and number of performers, but from his intuitive ideas about the duration of the stages. This approach is found in those managers who do not take care of resource management, they are rather concerned with just the schedule of stages. The consequences of this approach will be seen below.

A note to advanced users. In MS Project 2000, it is now possible to specify that some deadlines are expected, not accurate. A question mark is displayed next to such deadlines.

Task Sequence

Focusing on the priorities of tasks and features of the technology, the manager assigned a sequence of tasks. MS Project automatically highlighted in red the critical path of the project, i.e. those tasks that determine its duration. To shorten the critical path, the manager tried to start the next technological stage before the completion of the previous one.

Tips and comments.

The exact deadline should be specified only for the "Start Project" task, all other deadlines should be relative. Thus, you can always easily postpone the project to another date, all deadlines will be recalculated automatically.

All technological stages should be completed with checkpoints. The fact is that according to the technology, a certain finished result can be obtained only at a certain time, and it is at this moment that a control inspection of the project should be carried out. It often does not make sense to strictly and daily monitor the execution of individual tasks, because performers usually have to perform tasks in the wrong order as indicated in the plan. All this does not mean that daily reporting is not needed, it is needed in the form of reports on the cost of working time, which will be discussed later.
Do not use links between tasks of different levels. In this case, one technological stage is tied to the internal structure of another stage. This constrains the freedom to modify plans within the framework of individual stages. If you use relationships at only one level (task-task, stage-stage), you can easily change the composition and sequence of tasks within a certain stage.

Shortening the critical path of a project by starting tasks prematurely is very risky. Shorten the critical path through preparatory work (training, modeling, etc.). In our case, it is possible to plan prototyping simultaneously with the staged work, and thereby reduce the coding and the total duration of the project. Reducing the critical path of the project actually always leads to an increase in the cost of preparatory work. In other words, a reduction in the duration of the project, as a rule, leads to an increase in its cost or risks.
 

Remark 1. The beginning of the project in MS Project should be marked in its properties!

It is possible and milestone, the latter seems to me more convenient, because it can be dragged with the mouse.

Remark 2. Day-by-day reporting may and may be needed for some projects.

That's right, the specific nature of daily reporting is determined by the specifics of the project. For small software projects, daily reporting is usually enough as a report on the actual cost of working time.

Remark 3. The communication of tasks in the PMBOK should be at the lower level, and you recommend that you do them at the level of project stages.

PMBOK is not unambiguous here, there are two recommendations depending on the conditions. Communication is really recommended at the lower level, at the same time it is recommended to break a large project into modules and make connections between modules.

Guidance on managing implementation projects based on MS Project 2000 and PMI recommendations

Resources

After you determine the composition of tasks and their deadlines, the manager assigns resources to each task.

As a result, after specifying resources, the manager automatically receives a schedule of work.

Tip. If you want to account for administrative expenses, i.e. project management costs, you can use the following technique. It is necessary to specify in MS Project 2000 the manager as a resource for the entire technological stage. According to the duration of the stage, administrative costs will be taken into account in terms of labor intensity and cost. If the manager is running multiple projects at the same time, you can specify the percentage of the manager's workload for that project.

 

Remark. Wrong – resources set deadlines, not the other way around!

This is true, but as I noted above, many small project managers manage deadlines, but do not take on resource management. Paying tribute to this, he set the stage of determining the timing to the stage of determining the resources. In addition, it should be noted that we are analyzing an example of project management, the shortcomings of resource management in this project will be seen later.

Resource pricing

Guidance on managing implementation projects based on MS Project 2000 and PMI recommendations

Often, after receiving the work schedule, planning ends, but if you still need to approve the project budget, you need to assign a cost of resources.

Tips

Having an overtime is most likely a scheduling error due to the fact that you have assigned two tasks to one performer at the same time.
For planning, the time-based costing system is most convenient. This avoids complex bidding with contractors regarding the cost of work. It is enough to agree on the cost of a man-hour once, then the question is only in discussing the labor intensity.

We recommend that you use subset rates for resources. This avoids rounding errors.

In MS Project 2000 it is possible to use material resources. MS Project can remember inventory numbers, which is very convenient for accounting. Time-based depreciation of the operating system can be accounted for through the Std. Rate parameter. IBP-style write-offs can be accounted for through the Cost/Use parameter. In our example, the project requires the purchase of a server, according to the accounting policy we apply, the cost of the server is entirely written off to the project.
 

Remark 1. In addition to human resources, there may be other cost components.

It's like that. MS Project 2000 is able to take into account material resources. In addition, there are so-called company-wide expenses (FIU). However, most software companies include a specialist in the cost of a man-hour, i.e. the cost of Petrov's month is not his salary of $ 500, but another $ 1,000 general company expenses attributed to him. In the matter of FIU, the manager should contact the financial director of the company, if he is concerned about the profitability of projects, then he will calculate the NORM of the FIU for each employee. In MS Project you only need to enter it and you will get the full costs. If you need more sophisticated cost posting mechanisms integrated by the project system, it is worth looking for a higher-level project system.

Remark 2. You have no guidelines for using resource leveling.

I did not give them, because in a small project it is often easier to do an even distribution of the load manually and the use of leveling of many novice users frightens with its "unpredictability". We will give brief recommendations for alignment. Aligning is best if you have more than 10-20 tasks with no clear start dates, or you can't specify a task sequence but can prioritize them. Set priorities and run Resource Leveling in MS Project 2000 by enabling the "Priority; Standart”. The program will automatically assign tasks sequentially to resources based on their priority.

Remark 3. If you have agreed on the labor intensity and, accordingly, the price, then everything is that the payroll is no longer time-based, something is wrong with you.

Let's explain some of the subtleties of pricing for contract work. First, you agree on the cost of a man-month and enter it in MS Project 2000 as a Standard Cost Rate. Then you bargain with the contractor only about the term, the price is obtained automatically. After that, the term is fixed in the Base Line and exceeding the deadlines due to the fault of the contractor is not paid (unless you have agreed otherwise). An alternative option is to agree on both the price and the terms each time, with the price recorded in the Fixed Cost. In this variant, the cost of a man-month will float, which will complicate the planning of expenses, but is possibly useful in cases where the work by its nature (cost per hour) is very different.

Remark 4. It's not clear about rounding. And the days don't round up?

When calculating the cost of an hour and a day from the cost of a month, a day is 8 times more accurate than an hour by the number of valid decimal places. Here's an example. The cost of a man-month is $ 1500, which means the cost of the day with an accuracy of 2 digits is $ 68.18 (error $ 0.04 per month), and for an hour - $ 8.52 (error $ 0.48 per month). It can be seen that if you charge the cost as $ 1500 per month, there will be no error at all, but many managers for small jobs in a few days find it inconvenient, because by eye you can not check the daily rate with the Cost task.

Plan with budget

After assigning resource pricing, the manager automatically received a plan with a budget.

From this document you can see the following main project parameters:

• Duration
• Complexity
• Cost
• Time

Executors and responsible persons

Advice. Work and cost data can be used to pricing your project. In our case, you can multiply the labor intensity by the output price of the person-month and get the external price of the project. For example, if the output price of a man-month is $2000, and the labor intensity is 2 person-months, then the external price of the project is $4000. Of course, the price can be adjusted for marketing and strategic reasons.

 

Remark 1. How is labor intensity different from duration in your example?

Because MS Project 2000 understands this. If simplified work=Duration*N, where Work is labor intensity, Duration is duration, N is the number of occupied resources in the task.

Part II: Project Tracking. Risk management. Modification of the plan during the project
Quite often, after formal procedures for planning and obtaining a budget, project documents turn out to be a garbage can. The reason for this is that from the very first steps of the project there may be serious shortcomings in the planning, it may be found that the plan is subject to significant risks. It is necessary to carry out quite a difficult work on modifying the plan. For political reasons, the manager is often unable to do this for fear of losing face. As a result, the project begins to develop uncontrollably.

In Part II, we'll look at how to actually track projects.

Risks and indirect works

In our example, the following situation arose: no sooner had the project started than the manager discovered that his employees could not immediately start working, because the project is built on new technologies and they need to be studied. After analyzing the situation, the manager plans the training and again goes through the procedure for approving the budget and deadlines.

Such re-approvals of the budget and deadlines can be done infinitely many, if you do not analyze the causes of such problems. They are much deeper than the specific lack of staff qualifications. The fact is that most of the direct work that follows directly from the tasks of the project generates a large number of indirect ones that are related to their implementation. The problem is that it is impossible to accurately assess the composition and complexity of indirect work. Only statistical estimates can be given. On the other hand, indirect work is often driven by the impact of risks on the project.

In order to prevent indirect work from ruining the project, we can give the following recommendations:

• Plan training and quality. This prevents typical technological risks.
• Investigate risks and plan actions to prevent them. More on that later.
• Risk management
• Consider the theory of risk management.

According to the theory, you need to perform the following actions:

• Risk Identification & Quantification. It is necessary to conduct an analysis of the project in order to identify the causes of the risks. When analyzing risks, you need to check with the statistics of previous projects (Historical information). Risks should be assessed quantitatively (Risk Quantification). There should be a statistical assessment of the duration/cost of projects taking into account risks. The risks themselves should be divided into those that require special preventive actions and those that do not have a tangible impact on the progress of the project.
• Risk Response Development. It is necessary to clearly define the risk, its consequences and probability, to develop a strategy for its prevention. At this stage, a risk management plan should be developed. Both mandatory measures and measures should be developed for those cases where a certain risk has begun to have a negative impact (backup plan). It is necessary to provide a time and resource reserve, taking into account the impact of risks.
• Execution of the plan with risk tracking (Risk Control). It is necessary to carry out anti-risk measures and search for new risks.

An important conclusion follows from the theoretical recommendations: the plan can and should be subject to changes as a result of finding and eliminating risks.

Here are some examples of risk management documents that are useful in small projects.

Only statistics allow us to assess the significance of risks

The project is usually subject to a very large number of risks, it is almost impossible to plan measures to combat everyone. So what to do?

Guidance on managing implementation projects based on MS Project 2000 and PMI recommendations

You should refer to statistics. It is necessary to calculate which types of risks cause the greatest number of problems. The figure shows a graph of product defects depending on the types of defects.

You can see that the 80/20 rule works. Approximately 20% of the risks create 80% of the threat. It is on them that the main efforts should be paid. In high-tech projects, risks are usually prevented by training, quality control and maintenance (testing and other methods).

Tip. In order to effectively deal with risks, it is necessary to keep statistical records of emerging problems by type of risk. In this capacity, a system for accounting for product defects can be used.

 

Remark 1. There may be no statistics. In addition, risks tend to change over time.

What can I say? If there are no statistics for making a decision, then the decision itself will leave much to be desired. As for changes in risks, you need to track them as indicated above.

Remark 2. Risks are not only defects, but for example, incorrect determination of the sequence of task execution, inaccurate estimation of duration, etc.

For software projects, there is a feature. In fact, any team issuing good quality products has a bug tracking system. You can not reinvent the wheel and fix all risky problems there, for this you will need to start new categories of problems ("incorrect planning", "underestimation of deadlines", "error of setting the task", etc.). In this case, you will be able to use the developed reporting of problems from the defect tracking system, in addition, you will be able to use the mechanisms for tracking the problem, i.e. there will be a guaranteed response of the responsible person to the problem.

Reconciliation and reporting

After the approval of the new plan, the training was successful and ended in time with the necessary certification. The employee successfully proceeded to the first task. However, on the day of its completion, he reported that "the task is 90% ready and it takes another 1 day." The next day, he said the same thing.

The figure shows the view of the Tracking Gantt project, which shows the difference between the original plan and the actual execution.

What can be said about the current situation? The constant statement of the performers that the task is ready for "90% and you need a little more" is a sure sign of a failed task.

In our case, the manager understood this, called the employee for a frank conversation and began to find out the root causes of the failure to meet deadlines. They were as follows:

• The staff member stated that he was not involved in the decision on the timing of the task. This decision was made solely by the manager, although the deadline is clearly understated.
• The conversation showed that the employee himself is poorly oriented in the real timing of tasks. This is normal, only the manager concentrates on the timing and prospects. An employee is usually concerned about local problems literally within a few working hours.
• The discussion shows that the percentage of task completion report doesn't say anything. Perceptions of interest are subjective. More important is information about the real time spent on the project. The completed expenditure of working time is already a statistic for decision-making.
• Guidance on managing implementation projects based on MS Project 2000 and PMI

The deadline should be determined primarily by the executor. The performer is usually the most experienced expert in tasks of this kind. One should not be afraid that the executor will greatly overstate the deadlines, rather the term will be underestimated. The fact is that performers very rarely take into account in their assessments the need for indirect work.

Only deadlines agreed between the manager and the employee can be accepted into the plan. This allows you to share responsibility between them and avoid mistakes in estimating the timing. Microsoft Project has a built-in system for sending Messages to TeamAssign via e-mail or Web. This message is a mini-contract regarding the task between the performer and the manager.

In order to accumulate reliable statistics on real labor costs, it is necessary to keep records of working time for projects. The correct team status security questions are as follows:
what has you already spent time on (work complete)?
 

how much more time does it take (remain work)?

Microsoft Project allows you to automate the reporting of performers on the cost of working time and their forecasts through the mail or the browser. The information they provide is displayed in the plan. The manager, comparing the plan and the fact (more on this below), can judge the success of the project by timing and costs.

Remark 1. The manager must provide for indirect work. It is necessary to motivate the performers to take and execute tense plans, but to analyze the risks.

That's right, more on that below.

Methods for calculating the real deadlines of tasks

In our example, the manager found himself in a difficult situation. The most unpleasant thing is that the assessments of employees are unreliable and it is impossible to find out the full composition of the work.

The solution is to use statistical forecasting methods. Consider typical techniques.

Microsoft simply adds 30% to the total duration of scheduled tasks (Buffer time in 30%). This reserve is spent on covering risks.

The Load Factor method (or how many to multiply the programmer's words) recommended by the XP group. Statistical analysis of projects in small development groups showed that it is possible to find out the real deadline of the task quite accurately by simply multiplying the words of the performers by a certain coefficient. 

 

Here are the approximate values of the coefficient:

x2 – optimistic estimate
x3 is a normal project
x4-5 – application of non-standard technologies
 

A PERT scheme for calculating the real term. It is often the case that different estimates give different timelines; in this case, you can apply the method of calculating the real term using the following formula:

Real_Term=(Optimistic_Term+4*Expected_Term+Pessimistic_Period)/6

The coefficients in this formula (4 and 6) are obtained by analyzing the statistics of a large number of projects. It should be noted that the PERT scheme is only effective if there are indeed different estimates. If a manager wants to simply convince himself through PERT that his decision is the only correct one, then fitting the statistics will not give anything but a positive answer. How to use pert automation tools in Microsoft Project will be discussed below.

Important note. The static coefficients given are indicative only. It is necessary to accumulate their own statistics on the conduct of projects in order to obtain calibration coefficients specific to this technology and contractor data.