IT Project Management: A foolproof approach   Column published BrightPoint Consulting, Inc.   By Tom Gonzalez

In software development, project management can become one of the most challenging tasks to do successfully.  People view project management as an arduous task requiring lots of “non-productive” time managing schedules, budgets, requirements and complex project management software.  When it comes to running small projects on shorter timelines, project managers will tend to shy away from using any formal project management approach due to the perception of “unnecessary overhead”.  This does not have to be the case. Project management, when done right, should accelerate a project and make it easier, not harder, regardless of the scale.  In this article we will discuss how to take proven project management techniques and apply them to small projects to make them easier to manage and increase their chance of being successfully completed on time and on budget.

Any project, regardless of size, usually has three main measures of success: was it done on time; did it come in on budget, and does it deliver the requisite functionality.  In order to manage to these three objectives we need to create a specific plan that will allow us to achieve this.  Pragmatically, using a complex software management programs like Microsoft Project to manage small projects with only a few developers and a short time frame often turns out to be more effort than it is worth.  By the time you are done setting up and managing resources, critical dependency chains, costing, scheduling etc. you may have already depleted a significant portion of your budget.  The approach we will use here is a very flexible approach that does not require any software tools to support; it can all be done with a notepad and a pencil.

This approach has four main steps that are both flexible and powerful in that they can be applied universally to any type of project and work at various levels of detail.  The steps are as follows.

1.  Determine your significant milestones.

2. Estimate the work needed to complete the specific milestones.

3. Schedule your milestones to specific calendar dates.

4. Stay in a known state by monitoring your progress on regular basis.

1.  Determine your significant Milestones.

Defining your significant milestones is the process of breaking down your project into logical sequential steps. A milestone is something that has a definitive and measurable completion state.  Look for groups of tasks that reach a common end point.  The milestone “Start development” does not have an objective end point, but “Complete all User Interface Screens” does.  Each of these milestones might have smaller milestones within them, don’t worry about that for right now, as we move on to the subsequent steps we will have an opportunity to refine the level of granularity if needed. 

For time sensitive projects with firm deadlines, we can use a “working backwards approach.”  In this approach we start with the last task that needs to be completed at the end of the project, such as “train users”.  We then work our way backwards thinking “what needs to be done immediately prior to get to this step.”  By working backwards like this we force ourselves to think through each step in the process and it makes it easier to see every task along the way.  An added benefit for non-project manager types who may not have a lot of experience with full life cycle development, is that this process forces them to focus on the end goal versus starting with what they know and getting to an ambiguous stage of the project where they have a difficult time tying together the “Code is finished” step to “Train Users” step.

Let’s look at how we would apply this to a simple example.  In this example we have received a project request to deploy a one page website by January 11 of this year.  In order to identify all the milestones needed to complete this project, we will start with the last milestone, which could be: “Website Deployed and Tested on Production Servers”.  Next we start to think about what we have to do immediately prior to getting to that step.  In this case, the previous step might be: “Website  Deployed and Tested on Test Server”.  We can follow this process through for each preceding step and come up with a high level list of milestones in reverse order; such as the list below.

Milestone 7: Website Deployed and Tested to Production Servers
Milestone 6: Website Deployed and Tested on Test Servers
Milestone 5: Web Page Code Developed and Unit Level Tested
Milestone 4: Web Page User Interface Designed
Milestone 3: Web Page Prototype Approved
Milestone 2:  Project Scope Defined
Milestone 1:  Project Request Initiated.

2. Estimating the work required to complete your milestones.

After we have determined all of the significant milestones in their sequential and backward order we now want to estimate how long each milestone will take.  In estimating the time it will take to complete a milestone we might discover missing milestones, which is good. We simply add them to the list and make sure our list still follows a logical progression.  We might also discover that some milestones are really sub milestones of other tasks or not milestones at all; once again we just refine our milestone list.   

If we are having a hard time estimating the time needed to complete a milestone, or the time for one milestone is significantly greater than all the rest, that is the surest sign that you have not become granular enough in your milestones.  If we encounter this, we need to “chunk it down”.  This simply means that we will break the milestone in question down to a finer level of detail that describes the requisite steps to complete that milestone.  We keep chunking down these steps until we can feel confident in the time estimates we have created.  Be careful not to get too granular in chunking down your tasks, the goal is just to formulate a confident estimate in the most efficient way possible.

For example when we look at the milestone “Website Deployed and Tested on Production Server” we realize that we are having a hard time putting our arms around the true time required to complete this milestone. All we need to do is break the milestone down into smaller more discrete steps, following the same approach we did for the whole project.  We can also do this for any of the sub steps as well, until it becomes easy for us to put a time estimate to the specific step.  After we are done chunking down the milestone into its parts, we sum up the time needed for each sub part to get a reasonable estimate for how long the whole milestone will take to achieve.  The task list below shows all the sub parts and time required to complete Milestone 7 from our previous example.

Milestone 7: Website Deployed and Tested on Production Server: 9 hrs

   Step 7:  User performs web test from external web browser – 1hr
   Step 6:  User performs web test from internal web browser – 1hr
   Step 5:  Test machine connectivity - .5hr
   Step 4:  Enable Firewall – 1hr
   Step 3:  Deploy Web Pages – 2hrs
   Step 2:  Create Web Site on Server – 3hrs
   Step 1:  Validate Server is Connected to Network - .5hr

3.  Scheduling our milestones.

Now that we have identified all the milestones and the work required to complete them we will map the milestones to actual dates on a calendar.  We can either use a blank calendar, or draw one on a whiteboard or notepad.  Just like we did when we identified all of the milestones, we want to work backwards and start with the end date of the project.   This is especially important when we have a fixed delivery date.  This keeps the focus on the final delivery, which is often several steps away from the “we have finished all the code” step.   Sometimes we might even want to give our selves a little “pad”, and set our “end date” to a date before the actual due date.  Generally giving ourselves a 10%-15% pad should be sufficient.

We want to take into account the natural rhythms of the work day and week to map our milestones to particular calendar dates.  This means that our time estimates might not neatly fit into the calendar when a milestone delivery date happens to fall on a date the conflicts with the natural work window.  For instance, having a week long milestone end on a Monday morning probably is not realistic. It would be better to manage the schedule to have that milestone fall on a Friday, the natural ending point for the work week.  Or, if we have a high risk and time sensitive milestone we might want to buffer it with a weekend just in case some extra overtime hours are needed to take care of any problems that might occur. 

Using our previous website project example that has as due date of January 11 with total of  53 hrs, we might give ourselves a 1 day pad and set the end date of Jan 10^th.  For this example we will assume only one person will be working on the project with a normal 8 hour work day.

Milestone 7: Website Deployed and Tested to Production Servers – 9 hrs
Milestone 6: Website Deployed and Tested on Test Servers – 7 hrs
Milestone 5: Web Page Code Developed - 24 hrs
Milestone 4: Web Page User Interface Designed – 8 hrs
Milestone 3: Web Page Prototype Approved – 1 hr
Milestone 2:  Project Scope Defined – 4hrs
Milestone 1:  Project Request Initiated. – 0hrs

M (Jan 1) Milestone 1: 0hr Milestone 2: 4hrs Milestone 3: 1hr	Tu(Jan 2) Milestone 4:  8hrs	W(Jan 3) Milestone 5: 8hrs	Th(Jan 4) Milestone 5: 8hrs	F(Jan 5) Milestone 5: 8hrs
M(Jan 8) Milestone 6: 7hrs	Tu(Jan 9) Milestone 7: 9hrs	W(Jan 10) END DATE	Th(Jan 11)	F(Jan 12)

As you notice on the calendar, not every day includes a full 8 hours of work.  We try to plan a little padding into the schedule and take into account the natural workday.  We want to use some common sense when scheduling milestone completions and not have someone start an 8 hours task with half an hour left at the end of the day.  The calendar above reflects a reasonable timeline to accomplish our project and allows us to monitor the project on a daily basis. 

After reviewing this calendar, we might look at milestone 5, which has 24 hours allocated to it and realize we want to chunk it down so we can monitor progress a little more closely for that time period.  Our revised milestones calendar might look like this then.

Milestone 7: Website Deployed and Tested to Production Servers – 9 hrs
Milestone 6: Website Deployed and Tested on Test Servers – 7 hrs
Milestone 5c: Server Side code developed – 8 hrs
Milestone 5b: Database code developed  – 8hrs
Milestone 5a:  HTML code developed – 8hrs
Milestone 4: Web Page User Interface Designed – 8 hrs
Milestone 3: Web Page Prototype Approved – 1 hr
Milestone 2:  Project Scope Defined – 4hrs
Milestone 1:  Project Request Initiated. – 0hrs

M (Jan 1) Milestone 1: 0hr Milestone 2: 4hrs Milestone 3: 1hr	Tu(Jan 2) Milestone 4:  8hrs	W(Jan 3) Milestone 5a: 8hrs	Th(Jan 4) Milestone 5b: 8hrs	F(Jan 5) Milestone 5c: 8hrs
M(Jan 8) Milestone 6: 7hrs	Tu(Jan 9) Milestone 7: 9hrs	W(Jan 10) END DATE	Th(Jan 11)	F(Jan 12)

When we have mapped all of the milestones to the calendar, working our way backwards from the final delivery date, we might find that the start date has actually moved to a day in the past !  What does this mean?  This means, that our current project timeline exceeds the amount of time we have to complete the project.  We have two alternatives here, either we need to extend our project delivery date (which is sometimes an option in less time sensitive projects), or we need to accelerate our project timeline.  Most often we need to explore the second alternative.  Here are two possible ways to accelerate our project timeline:

           Option 1:  Rework the milestone delivery dates.  Can any milestones be developed in parallel; is it possible to stretch each work day to accomplish the milestones on a quicker schedule?  Can we add resources to the project to get milestones done more quickly?  The negative side effect here is usually added project cost either due to overtime or having additional resources added to the project, but the positive result could be keeping the project on schedule.

          Option 2:  Reduce project scope.  This means reducing some level of functionality the project was going to deliver upon. This is usually only effective in the earlier stages of the project.  Once a significant amount of development has occurred there will be diminishing returns on trying to reduce project scope since most of the work has been done and it often creates more work to “undue” functionality.

4. Staying in a known state.

The final step in managing our project is not just one step, it is a continual process called “Staying in a known state.”  Staying in known state is the biggest KEY to successfully managing your project. This doesn’t mean that your project won’t have problems like missed schedules or budgets, but it does mean that your problems will be anticipated, minimized, and ideally - mitigated.  The easiest way to stay in a known state is to use your project calendar like a lifeline.  The team should be focused on the current milestone and treat each milestone as fixed date that needs to be met.  This focus should be kept regardless of where you are in your timeline, a 3 day slip in week one of the project is just as important as a 3 day slip near the end.  It is often these “little” slips that build up over the project lifecycle that make delivery dates so hard to hit. 

This milestone delivery schedule is what drives the project and everyone on the project team.  At least once a day check in with the team and monitor forward progress, these check-ins can be informal chats or regularly scheduled status meetings.  You goal here is to uncover any information that could take you out of a “known state” and jeopardize your delivery schedule.  Three main topics to cover when checking in with the team are: 

1. Are we on target ?  If not, what happened and how do we resolve ?  Have we encountered any unknown issues?

2. Or has something changed from our previous check-in?

3. Does everyone have the information and resources they need to continue to move forward?   If not, what information or resource do we need to obtain?

Often time is these meetings we do discover that things are not going perfectly smoothly and something has slipped.  This is okay, having a slip is normal and expected for most projects. The important thing is to know that you have a slip early while we have time to correct it.  Not knowing things have slipped until many days after the slip is probably the biggest reasons why project deadlines are not met.  When we have a slip we need to reassess every milestone from that slip on and redo our calendar schedule, updating each milestone, in effect redoing the third step in our process for each slip.  The sooner you identify a slip, the less costly it is to the project. 

By following these 4 project management guidelines, adapting them to your own projects, and being disciplined in your execution of these four steps you will have projects that are done quicker, cost less, and are more enjoyable to manage.