Using MS Project to manage software development projects

I want to share my experience using MS Project to manage software development projects. I've been doing project management for 10 years,
and as a result, I was born with some methodology for using MS Project, which allows you to get a lot of benefit from it and at the same time be less dependent on its shortcomings.

Small introduction

The whole methodology is simply a set of simple methods and recommendations for using MS Project for solving applied tasks of a project manager. At once I will make a reservation that the methodology does not claim to be universal, and is applicable only under certain restrictions, which I will mention in the course of the narration.

To begin with, let's remember what is usually required of a project manager. For experienced managers, this is obvious, and for beginners (or just about to become leaders) it will be useful to remember once again. So, a software development project is the creation of some unique product. At different stages of the project life cycle, the PM is required to solve various tasks.

Before the start of the project

Before starting a project, a project manager is usually required to answer two questions:

1. how long will the project take
2. how much the project will cost

At the same time, it is important to understand that no one is interested in the answer of the form “not earlier than in six months”. It requires just an estimate from above.

Note I have never had to deal with a clear monetary assessment of the project, and, as I now understand, this is a serious omission. All the projects I managed were executed by the company employees. The project team was formed for the entire project time, some specialists were involved for a certain time. In fact, I am required to estimate the number of required performers, as well as the timing of their involvement. As it seems to me, this is a rather typical situation for software development companies. In the end, it all comes down to an estimate of labor costs, which, using empirical formulas, turns into an estimate of the cost of the project. As we see, there is a direct dependence of the cost of the project on its terms.

')

During the project

In the conditions of the mentioned restrictions, the main task of the project manager is to ensure the implementation of the project within the stated period, and this
affects its value. Unforeseen circumstances, which necessarily accompany any project, may lead to failure to meet deadlines. Strictly speaking, the terms of the project may unexpectedly be shortened, but, to be honest, I have never seen anything like this. The manager is required to respond to such events in a timely manner in order to reduce the negative consequences. The only way I know how to solve this problem is careful planning, regular tracking of impending problems and updating plans.

At the completion of the project

At the completion of a project, the manager usually looks back and summarizes the project. Most often, it is necessary to assess how much the project is out of the planned schedules and why it happened.

What can MS Project

Despite the external complexity, MS Project is very simple in terms of ideas. It operates with three entities - tasks, resources, calendar and connections between them. In essence, this is a database, a user interface for creating and editing entities, and minimal, fairly simple automation (what Project itself does in response to the entered data).

Let us briefly examine the properties of entities.

A task has a duration, a volume, an assigned resource, and a damn lot of different properties. If the built-in properties are not enough, you can add your own - we will use this later. Tasks can be interconnected by different relationships (predecessors, followers, etc.).

The resource has many descriptive properties, but the most important thing is that it can be
set availability in time, for this is used calendar. Resource can be
assigned to the task.

Based on this data, the Project can make various presentations using
filters, groupings, sortings, etc. In addition, he can according to some algorithm
calculate the start and end dates of tasks, taking into account the availability of assigned resources
and connections between tasks. Here, in fact, almost everything that he can.
Let's see how you can benefit from it.

How to use it

Note To make it clearer, I will clarify some common properties of projects
with whom I worked. So, we are talking about software development projects,
which consist of several stages. At the end of each stage we have to get some
tangible result that will be presented to the customer, so it is important for us to evaluate
term not only the project as a whole, but also each stage. I repeat, the only kind of resources
which is required - these are people, and we do not hire outside specialists, but use
opportunities already working employees.

Plan preparation

So, we have a technical task, and we need to answer three questions:

1. How long will this project take?
2. How many (and what) specialists will be required for this?
3. What are the estimated labor costs for this project?

To do this, we are preparing an approximate project execution plan in MS Project. Those. simply write tasks that need to be completed. The technique of turning a technical task into a set of tasks is a separate story, I will not dwell on it now.
Preparation of the plan is carried out in several stages:

1. Preparing a list of tasks
2. Set dependencies between tasks
   (what task result is needed to go to the next one?).
   
3. Assign task executors
   
4. Align resource loading
   
5. Balancing what happened
   

General recommendations

In preparing the plan, we follow the following recommendations:

1. We do not use summary tasks for decomposition.
   All tasks are placed in one linear list. At first it may seem awkward,
   but it eliminates many problems in the future. To manage the structure of tasks
   use custom fields (see below).
   
2. Very often, Drag & Drop is used to manage task dependencies. When a lot of tasks it quickly becomes uncomfortable. In this case, I recommend not to use dragging, but explicitly indicate the numbers of predecessor tasks. To do this, you can add a “predecessors” column to the table and enter task numbers manually.
   
3. The duration of each task should not exceed two weeks.
   If the task is longer than a week, this is a reason to think about its decomposition. I adhered to a very simple assessment methodology: a primitive task - 2 days, an average
   Difficulties - 1 week, difficult task - 2 weeks. At the same time, there should not be many complex tasks. This approach makes it possible to prepare an evaluation plan fairly quickly.
   On the one hand, the estimate obtained, of course, will not be accurate, but, on the other hand, which one is accurate? By practical experience, I can say that
   For large projects, the error estimates of individual problems are usually leveled, and for small projects it is often possible (and necessary) to use more accurate estimates.
4. By all means we avoid tasks that have several performers. For each task must be assigned only one performer. It makes sense to assign two performers
   only if they really work together (for example, you practice pair programming). In other cases, it is better to decompose the problem.
5. When appointing performers, we are guided by their profession and qualifications, while not worrying about the uniformity of loading.
6. We use summary tasks to divide tasks into stages. Put the dependencies between the stages so that they go sequentially. The division into stages is rather approximate.

Task List, divided into stages

Project balancing

The most important thing in the method is balancing. The purpose of this process is to prepare a plan in which the works are fairly evenly divided between the performers throughout.

After the initial preparation of the plan is usually obtained a complete disgrace, not a project. Therefore, we begin to bring it in order. Tidying up consists of manual balancing of appointments of performers and divisions into stages. To do this, use the grouping of tasks by performers to see how the tasks have decomposed. For viewing convenience, I recommend sorting tasks by start date.


Task grouping by artist

Note. Theoretically, it is assumed to use graphs to estimate the load
user downloads. These graphs are good (probably) for bosses when they
evaluate the finished project. But they are unsuitable at the stage of creating a plan, as they show
that everything is bad, but it gives no information at all why this is so and what can be done.

Then begins the magic of balancing. It is required to minimize the deadlines for the implementation of each stage by ensuring a more or less uniform load on all project participants. To do this, we perform the following actions:

1. Change the task executor.
   
   It makes sense to do it if we see that one performer has a big tail of tasks,
   and the other has obvious “holes”, and he can take on some work from
   first.
2. Move the task to another stage.
   
   The task that leads to the lengthening of the term stage, but it is not necessary
   to obtain the result of the stage can be transferred to the stage later. And vice versa,
   if at the stage there are “holes” in the download of performers, and change the performers
   does not work, then you can try to take the tasks from the next stage.

Unfortunately, all this has to be done manually, by equalizing the load on resources after each change. Despite the apparent complexity, this process usually takes finite time. The project for a year of 8 participants, divided into 4 stages, I put in order in less than an hour.

Now, once again carefully look at the project, we are convinced that the links between the tasks are set correctly, that nothing is forgotten, and the appointments of the performers correspond to their specialties and qualifications.

Risk management

Now - the final touch: risk management. Frankly, I did not deal with serious risk management, but consider the possibility of certain force majeurs (such as performers' diseases, forgotten jobs, etc.). To do this, I add to each stage a fictitious task with a minimum priority, called “other works” for each resource. After resource alignment, these tasks are at the end of the stage. The duration of these tasks depends on the probability of occurrence and the degree of risk exposure, it depends on the method of determining the estimated durations of the tasks, the health of the team members and the degree of paranoia of the project manager. Usually, I exhibited the duration of “other works” from about a third to a quarter of the stage length.

As a result of all the above manipulations, we have a project execution plan with which to work.

With this plan we can:

1. Name the deadlines for the project and its phases. Reasoned and with a high degree
   authenticity.
2. Estimate the estimated project effort

Note. It often happens that the deadline is quite long, and a reasonable question arises whether it can be reduced by attracting additional performers. In order to answer this question, I balanced the new plan, using the same set of tasks, but changing the cast. The answer did not come instantly, but it did not take long.

Work with the plan

When a project is put into operation, the original plan that was used for the evaluation can be used to track the progress of the project. The project manager is required to regularly perform the following actions:

1. Issue tasks performers
2. Mark completed assignments
3. Adjust the plan in case of significant deviations

Issuing tasks performers can be done in different ways. You can break the execution into short iterations, form a pool of tasks per iteration and at the end of the iteration note the results. You can immediately announce to the customers a set of tasks for the stage, give each of them a copy of the Gant chart and periodically ask about progress. You can use the integration of MS Project and TFS and upload the project directly to TFS. The point is not in the means. The main thing is to regularly update the plan . I do it about once or twice a week. This makes it possible to quickly see problem areas.
To identify a problem area, it is convenient to use different groupings - by executors, by components, etc. It can often be that the project as a whole is even ahead, but there is a lag in a certain section, for example, one of the developers unexpectedly bumps into a serious system problem to deviations. Using only the average metric will not show this problem - it will pop up only at the end of the stage, when something will be done too late.


Performance Tracking with Component Grouping

Note. I usually do not move tasks on the calendar, but only note how they are completed. I follow the deviation from the plan by the deviation of the total project task from the current moment.

There is another strategy - making changes to the deadlines of the tasks, “pushing” the unfulfilled tasks forward. With this approach, another useful feature of MS Project, the basic plan, can be used to track deviations from the plan. The baseline is just a saved snapshot of the task status. It can be done at the beginning of the project. To compare the current plan with the baseline, open the “Gantt chart with tracking”. For a dynamic plan, when the order of performing tasks often changes, this can be inconvenient, so I insert test points in the project that reflect some important project results and track deviations from the base plan for them only.


Tracking Gantt Chart

Manage task structure using custom fields

I strongly recommend not using summary tasks in MS Project for functional decomposition or categorization of tasks. The fact is that the hierarchy of tasks in MS Project is strongly tied to their sequence. And often you want to look at the tasks in different sequences, while the whole structure "crumbles." I recommend using Custom fields to control the structure of tasks. MS Project has a predefined set of fields with unspecified advance behavior that we can use as we see fit. For example, to break down tasks by component, on the basis of the Text1 text box , create the Component field and set a list of values ​​for it corresponding to the system components.


Create custom field

After that, we are able to specify for each task the components to which it belongs, and, using the grouping of tasks by components, to track how things are going.


Task grouping by component
Custom fields allow you to divide tasks into several categories, for example, I divided tasks by type of work: Development, Testing, Documenting.
I will mention to the curious that in MS Project you can also set rules for drawing diagrams based on task properties. If desired, you can make the tasks for different components have different colors, and the color will be determined only by the property of the task, it does not need to be set manually for each task. Such settings do not require writing scripts, but are made using standard chart setting tools.

Using custom fields, as well as filtering, sorting and grouping tasks built into MS Project, you can get a variety of ideas that allow you to get answers to many questions that arise from the project manager.

Completion of the project

At the end of the project we get a plan in which all tasks are completed. I usually try to keep the original plan as well, at least as a baseline. Honestly, at this stage, MS Project is of little use, since it is not the planned values ​​that are of interest but actual values. MS Project Server offers some solutions to this problem, there is an opportunity to take into account the actual labor costs, but this is beyond the scope of this article.

Conclusion

I tried to summarize my experience of using MS Project for the practical solution of problems that arose before me when I was in charge of software development projects. The described method does not pretend not universality, but it seems to me that it is quite simple and logical, while it allows you to solve practical problems of the project manager.
Using this approach allowed me to successfully complete more than one project on time.
True, there were failures. This happened, as a rule, when the preparatory part of the project was poorly carried out, namely, the formulation of the problem. Those. as a result of the project, it was not exactly what was required, but the understanding of this came too late.

Surely I missed something, do not hesitate to ask questions.