There is a general misconception that Microsoft Project, or many of the commercially-available project management applications, doesn’t work well for software development projects. When talking with Project Managers and Architects, their trouble usually arises from scheduling and resource leveling. They’ve usually been burned by situations where countless hours have been invested into building out a project plan only to find that a minor change skews the plan into an almost unusable mess. There might be many things going on at the same time, but it usually boils down to an understanding of the difference between Duration and Work.
Conceptually, this isn’t a hard distinction. Most people can tell you that Duration is the calendar time it takes to get a task done whereas Work is the number of development hours it takes to complete a given objective. However, in the middle of a project, the distinction is easy to miss especially when the business objectives and the actual project work-stream are expressed in different terms. The business stakeholders want to know when functionality will have to be handed off to other groups for activities like integration testing, security audit, and user acceptance testing – ultimately, when will the functionality be delivered. On the other hand, the development team is used to thinking in development hours and estimated work remaining. All of this is made more complex by the fact that MS Project’s default view is expressed in Duration.
Let’s look at a simple example based on the following Work Breakdown Structure (Not complete, just an example):
|1.0 – Users can log into the web site (Authorization) and are granted access according to their assigned authorizations||80 Hours||0 hours||80 Hours||Use Case 1.0|
|1.1 – Develop custom logon control for the upper-right in the Master Page header||20 hours||0 hours||20 hours||Use Case 1.0|
|1.2 – UX Design for logon flows||8 Hours||0 hours||8 Hours||Use Case 1.0|
|1.3 – Forgot Password Functionality||20 hours||0 hours||20 hours||Use Case 1.0
Alternate Flow (Forgot Password)
|1.3.1 – Forgot Password Challenge Question||12 Hours||0 hours||12 Hours|
|1.3.2 – Forgot User Name e-mail process||8 hours||0 hours||8 hours|
I’ve put in a little bit more information into this WBS to prove a point. As you go through your initial planning (at the user story/ product backlog/ use case level) you will be looking at a time-based measurement. Likewise, when you are handing that work into the development queue, the estimates that you will arrive at in your sprint plan will be based on effort. Don’t work if you are using story points at the highest level. These eventually get translated into hours, and should be considered a substitution for the effort measurement.
Pasting this into MS Project 2010, it is tempting to just use the standard Gantt chart, but that leads you directly into the wrong path.
Notice that the column on the default view is Duration – that is, calendar time that is required to get the task done. This works if there is only one person (or resource) working at a time, but this quickly breaks down when you have a team or several teams working on the project at once. Instead, you need to add the Work column to the Gantt chart.
- Scroll the tabular view to the right until you can see the ‘Add New Column’ heading
- Click on the menu arrow to see the list of available fields
- Select the Work Field
Once the actual work is entered for the individual work packages, all items will automatically be marked as Effort Driven and the project plan can be leveled against the resources. Here I have added myself as the resource and have allowed MS Project to rebuild the schedule.
The Final Project Plan
Allocating an additional resource to some tasks in the project (John Gault, in this case) keeps the development effort the same, but MS Project 2010 shortens the overall duration of the project to take advantage of the additional work capacity. With the additional resource, we’ve shaved 2 days of duration off of the project.
Just be sure that when you add additional resources, you tell MS Project how this should affect the task.
With a little planning and attention to work estimates rather than only duration, MS Project can be a huge asset to the software development team. This work/effort-based tracking is vital to effective sprint planning and allows the project team to quickly visualize the workstream against the sprint capacity. This also helps to focus the team on critical path issues that might be missed in a taskboard exercise.