I would like to share my experience in applying MS Project to management of software development projects. I’ve been working in project management for about 10 years. As a result, I have developed a certain methodology for MS Project application, which increases benefits from this software and reduces its drawbacks.
The whole methodology is simply a set of simple methods and recommendations on using MS Projects for solving applied problems of a project manager. Let me specify in advance that this methodology doesn’t claim to be universal and is applicable only under some constraints, which I will mention along the way. For a start, let’s remember common requirements imposed on a project manager. These are obvious for experienced managers, while newcomers (or those who are just becoming managers) will certainly benefit from identifying these issues once again.
A software development project implies creating a certain unique product. Various stages of project life cycles require PM to solve different problems.
Before Project Kick-Off
Before project kick-off, a project manager is usually required to answer two questions:
- How long will the project take?
- How much will the project cost?
Meanwhile, it’s important to understand that answers like “this will be clear in half a year at the earliest” are unsatisfactory; upper-bound estimates are what is needed.
Note. I have never dealt with monetary assessment of a project and, as I see now, it is a serious omission. All the projects I managed were implemented by company employees. Project teams were appointed for the entire project implementation period; some experts were engaged for certain periods of time. For better analysis, I should evaluate the required number of resources (“resource” means “performer” or “doer” in MS Project) and the periods of engaging them. I suppose that this is a rather typical situation for software developing companies. Eventually, it all comes to evaluation of the amount of work which is turned into project costs evaluation by application of empirical formulas it. As we can see, project costs are directly related to project implementation time.
During Project Implementation
Taking into account the above-mentioned constraints, a project manager’s main task is to ensure implementation of the project within a stated period of time, project costs being directly influenced by this condition. Unforeseen circumstances which always occur in projects may cause a failure in meeting time constraints. In addition, project implementation time may also suddenly be shortened, although I have never faced such a situation. Managers are required to respond to such events swiftly in order to mitigate adverse consequences. The only way I know to deal with this task includes careful planning, regular tracking of imminent problems, and correction of plans.
At project completion, managers review and summarize project results. Very often, it is necessary to evaluate how far behind the planned schedules the project was, and why this happened.
MS Project Capabilities
Despite appearing complicated, MS Project has a very simple concept. It handles three entities (tasks, resources, calendar) and the relations between
them. It comprises a data base, a user interface intended for entities creating and editing, and a rather simple automation (the actions performed by Project in response to the entered data).
Here is a brief description of the entities. A task features certain duration, volume, assigned resources, and various other characteristics. If incorporated features are not enough, it is possible to add your own (we will show this possibility later). Tasks may be related to one another in various ways (predecessors, successors, etc.) A resource has many descriptive features, yet the key is in the possibility of setting availability in time, which is what the calendar does. Resources can be assigned for a task. Based on this data, Project is able to do various presentations applying filters, grouping, sorting, etc. In addition, it is able to calculate task start and finish dates according to a certain algorithm, taking into account assigned resources availability and relations between the tasks.
That is really all Project can do. Let’s see what use we can make of it.
Note.For better understanding, I will clarify some common features of the projects on which I have worked. We shall speak about software development projects comprising several stages. At the end of each stage we should get some tangible result to show to the customer, that is why it is important for us to evaluate the implementation period not only of the whole project, but also of each project stage. Let me repeat that the only required type of resource is the human one; moreover, we do not hire external experts, but involve our working staff.
We have requirements specification ready, and need to answer the following three questions:
- How long will the project take?
- How many (and what) experts it will need?
- How much work is expected to be done for this project (approximately)?
For this purpose we plan an estimated project implementation schedule in MS Project. That is, we write out the sequence of tasks we should complete. The method of converting requirements specification into a set of tasks is a story in its own right, and I will not dwell upon it now. Schedule planning includes several stages, where we do the following:
- Prepare the list of tasks.
- Set the correlations among the tasks (what task is necessary to pass to the next one?)
- Appoint tasks resources.
- Equalize resources workload.
- Balance the results.
While planning a schedule, we keep to the following guidelines:
- We do not use rollup tasks for decomposition. All the tasks are included in a single linear list. At first it may seem inconvenient, but it will eliminate many problems later on. In order to manage the tasks structure we use custom fields (see below).
- Drag&Drop is frequently used for managing tasks correlations. In cases of numerous tasks this practice is impractical. Here I recommend not to use dragging, but to state the numbers of preceding tasks clearly. To do this, just add a column called “Predecessors” into the table. Task numbers may be entered manually.
- Implementation period of each task should not exceed a fortnight. In case it does, you should consider decomposing this particular task. I keep to a very simple evaluation method: a primary task takes 2 days, an intermediate one – a week, a complex one – a fortnight. There should not be many complex tasks. This approach facilitates rather swift preparation of an estimated schedule. On one hand, the resulting estimation will not be precise; on the other hand, what estimation can claim to be precise at all? As a matter of practical experience, I can say that large projects tend to offset errors in separate task estimations, while small-scale ones often may (and need to!) apply more accurate estimations.
- We should do our best to avoid tasks having several resources. A single resource should be assigned for each task. Appointing two resources makes sense only when they really work together (for instance, you practice pair programming). In other cases, it is best to decompose the task.
- When appointing resources, be guided by their profession and qualification only; at this point, do not worry about workload uniformity.
- We use rollup tasks to divide tasks into stages, setting correlations between the stages to place them in sequence. Division into stages is still rather rough.
Fig 1. List of tasks, divided into stages.
The key to the method lies in balancing. This process is aimed at planning a schedule where works are fairly uniformly distributed among the resources during the whole process. Primary schedule planning usually results in a complete mess; therefore, we begin by putting the project in order. This process involves manually balancing resources’ appointments and division into stages. To do so, we apply the function of grouping tasks in relation to resources in order to see tasks distribution. I recommend that you sort your tasks by starting date for ease in viewing.
Fig 2. Grouping tasks in relation to resources
Note. In principle, workload is to be estimated with the help of user workload diagrams. These diagrams are fine (or may be fine) for managers when they evaluate the prepared project. However, they are of no use in the schedule planning stage, as they identify everything as bad, but not why it is so, or what can be done about it. Here begins the magic of balancing. It is necessary to minimize each stage completion periods by distributing the workload more or less equally among all the participants of the project. For this purpose we do the following:
- Replace the resource of a certain task.
It makes sense when we see that one resource faces a long queue of tasks, while the other one has obvious “gaps”; moreover, he is able to undertake some works of the first one.
- Move the task in question to some other stage.
The task-extending stage completion period, not yet essential for obtaining the stage result, can be moved one stage later. Vice versa, if a stage features “gaps” in resources’ workload and it is impossible to replace the resources, we may try to take tasks from the next stage.
Unfortunately, we have to do this all manually, equalizing the resources workload after each alteration. In spite of seeming complicated, this process usually takes a measurable period of time. A year-long project involving 8 people, and divided into 4 stages, took me less than an hour to correct. Then we look at the project attentively once more, ensure the correlations between the tasks are set correctly, nothing is left out, and resources’ appointments correspond to their professions and qualification.
Risk management will be the final topic here. I have never delved deep into risk management and I do not want to touch upon all these important things like risk management plan, countermeasures for each risk and so forth. I just do take into account certain forces majeure (e.g., sickness, lost work, etc.). To do so, I add a fictional task of minimal priority, called “miscellaneous works” to every stage and for each resource. Resources equalizing completed, these tasks turn up at the end of a stage. Their implementation period depends on the probability of risks arising and the degree of impact these risks may cause. It also depends upon the way we choose the methods of tasks implementation period estimation, on the team members’ health, and the state of the project manager’s paranoia. Usually I set miscellaneous works duration approximately a quarter or a third of the stage duration. As a result of these listed manipulations, we get an applicable project implementation schedule. Using this plan we can do the following:
- State implementation time frame of the project and its stages reasonably, and to a high degree of accuracy.
- Evaluate approximate amount of work that should be done for the project.
Note.Implementation period often turns out to be rather long, and a reasonable question arises: can it be shortened by involving additional resources? In order to answer this, I balanced a new schedule using the same list of tasks, changing the resources’ team line-up. I did not receive the answer instantly, but it never took long.
Working with the Schedule
After the project kick-off, the initial schedule used for estimation can also be applied for tracking the project implementation. Project manager should regularly do the following:
- Give tasks to his resources.
- Remove the completed tasks from the schedule.
- Correct the schedule in case of significant deviations.
Assigning tasks to resources can be done in various ways. It is possible to divide the implementation process into short iterations, form iteration task pools, and check off the results at the end of iteration. You can give all the tasks of a certain stage to the resources, providing everyone with a copy of the Gantt chart, and inquire about the progress regularly. It is also possible to use MS Project and TFS integration to download the project directly to TFS. The key lies not in the means, but in regular schedule updating. I do it approximately once or twice a week. It enables me to see problem areas rather quickly. Various kinds of grouping (in relation to resources or components, etc.) are convenient for problem areas detection. It may frequently happen that, on the whole, a project is ahead of schedule, but there is a lag in a certain section of the project: for instance, one of the developers suddenly faced a serious system problem which caused deviations. Application of average metrics alone will not reveal the problem, as it will appear only at the end of the stage, when it will be too late to do anything.
Fig 3. Implementation tracking, grouping is done in relation to the components
Note.Usually I do not move tasks by the calendar; I mark the degree of their completeness instead. I track schedule deviation by examining deviation of the project rollup task at the current moment. One more strategy implies alteration of task time frames, “pushing” incomplete tasks ahead. This approach enables you to use another useful MS Project function, namely baseline, to track schedule deviations. Baseline is simply a saved screenshot of task status. It can be taken at the beginning of the project. In order to compare the current schedule with the baseline we open “tracked Gantt chart”. This method may turn out to be inconvenient for a dynamic schedule where the order of tasks implementation changes frequently. Consequently, I provide my project with certain inserted milestones showing some important project results, and track if they alone deviate from the baseline.
Fig 4. Tracked Gantt chart
Managing Tasks Structure with Custom Fields
I positively do not recommend using MS Project rollup tasks for functional decomposition or task categorization. The reason is that MS Project tasks hierarchy is closely related to their sequence. You may want to view various tasks sequences, in which case the whole structure “falls to pieces”. I advise using Custom fields for managing tasks structure. MS Project has a predefined set of fields, the behavior of which is not defined beforehand. We may use these fields at our convenience. For instance, in order to break tasks down in relation to components we need to create Component field on the basis of Text1 text field and set the list of values (LOV) for this Component field in accordance with the system components.
Fig 5. Custom field creation.
We then have the opportunity to provide each task with a component to which this task is related and can track the situation by grouping tasks in relation to components.
Fig 6. Tasks grouping in relation to components
Custom fields allow separating tasks into several categories; for instance, I categorized my tasks in relation to work type: Development, Testing, and Documenting. For those who are curious, let me add that MS Project also allows setting chart creation rules based on tasks features. If required, it can be done in such a way that tasks related to different components will be shown in different colors, the color being defined by the task feature only, and there is no need to set it manually for each task. Such settings require no script writing, being adjusted by standard means of charts customization. Custom fields application along with task filtering, sorting, and grouping functions incorporated into MS Project enable us to get all kinds of information which provide answers to many questions raised by a project manager.
At the end of the project we see a schedule where all the tasks are completed. I tend to keep the initial schedule as well, to use as a baseline. Practically speaking, MS Project is of no great use at this stage, as we are interested in actual values, not the scheduled ones. MS Project Server suggests some solutions, providing a possibility to take into account the actual amount of performed work, but this issue exceeds the framework of this article.
I have tried to summarize my experience in applying MS Project for dealing with practical problems I faced while managing software development projects. The described procedures do not claim to be universal; however, they are fairly simple and logical, and enable a project manager to deal with practical problems he/she faces. Applying this approach, I managed to complete more than one project successfully and on time. Of course, several failures did occur. In other words, project results were not exactly as required. As a rule, they were caused by poor project preparation; i.e., by low-quality requirement specifications. It was not possible for me to address every possible issue in my article, so do not hesitate to ask questions.