At the outset of all our projects, we define work breakdown structures, resources, durations and eventually agree upon a project schedule. As we wade into the project, we begin tracking progress against the schedule baseline and tick off the activities as they complete. What happens when we begin to slide to the right and what techniques can we all use proactively to either minimize the chances of sliding to the right or ideally stay on schedule? There are multiple techniques I have used in my projects to stay on schedule.
Front load the work
How many times have we all heard the cliche "Stuff happens?" And in reality, how very true is the statement? In my experience, there are always unplanned activities or setbacks on a project that both eat away at the available capacity and typically push the schedule to the right. So how do we plan for the unexpected?
When both planning and controlling a project, I front load the work. For an activity that has float, I start at the earliest possible date given resources constraints. This may be the early start date or earlier. Keeping the resources utilized at 100% from the beginning is crucial to both building momentum on the project and getting ahead. The tendency is to start slow and pick up speed later. I take the opposite approach by starting early and keeping a steady strain throughout the project.
So when I plan the project, I take the hardest activities and schedule them early on assuming all dependencies are satisfied. This positions the project manager to best absorb those unplanned activities when they occur. If the project manager is caught up short, then more time is available to catch up.
As an example, I would build out and install applications in a DEV environment while the up front planning and requirements are being gathered. This activity could easily be pushed out as no development work has to occur very early on. What happens if the hardware is not available or there are issues with network connectivity or the software delivered is the wrong version. These are examples of possible unplanned issues that could arise which can push the schedule to the right. If we execute these activities early then if issues do arise, we have more time to address them. There are exceptions such as training of end users before a deployment as an example. Clearly, the timing of this is back loaded but training is an exception and not the rule.
To summarize, plan the difficult activities early and enstill a sense of urgency from the first day so time is not lost at the beginning of the project.
Pad and protect the critical path
As we all know, the critical path drives the schedule so protecting and closely monitoring critical path activities is a good idea on any project. The idea of padding the schedule is not something new, but focusing this only on the critical path activities is worthy of note. If the non-critical activities do not impact the schedule, then padding them only increases project cost so focus any padding on the critical path activities only.
Typically, I will add 25% to the durations defined by those estimating. The amount appropriate is a number defined by the project manager after getting some experience with the team and especially the individual making the estimates. The accuracy of any individual estimate is function of the individual. There are some people that 25% is fine as their estimates are typically spot on. Others might be 50% or even 100% off as they hone their skills in this area or more typically define the amount of time it would take them to perform the task. There are cases where the estimators are highly skilled and efficient technicians and those that will perform the tasks are not as highly skilled so the estimates become systematically low. The project manager needs to know their staff and make adjustments where appropriate.
Marathon and not a sprint
Projects are long term endeavors by definition. They can range from a few months to years in length. In the first suggestion on staying on schedule, I spoke about front loading the work which remains true. There is a tendency among people to try and finish everything in the first few weeks. Over time, I have had individuals work nights and weekends very early in the project and wear themselves out. In two extreme cases, the technicians made themselves physically ill from overwork and one even had double pneumonia. In these cases, significant work time was lost in the recovery.
From the outset in a project, I stress to the project team the project is a long term endeavor and we need to find a work and travel schedule, if applicable, that we can sustain for many months. In our business, a 40 work week is something we all look and hope for but an 80 work week is not sustainable. In the projects with off-shore components or with wide time zones differences, the early mornings and late nights can take a toll on resources.
The work schedules need to be worked out and only increased in few situations. Even in those situations, the length of time to work deep into evenings and over weekends is limited to less than 5 consecutive work days and 2 weekends. The tendency of project managers when getting behind in schedule is to increase work hours but this can have dire consequences such as resources getting sick, resigning, or decreased productivity due to fatigue. If more time is needed to recover the schedule, the PM should consider formally moving the schedule to the right.
In one case, a project team in the middle of a testing cycle had an enormous number of open issues and my predecessor continued to ramp up working hours. As the hours increased, the productivity dropped and the situation got worse. One of the first things I did was to cut back on the hours worked and saw an increase in productivity. Each team will determine the appropriate schedule so keep in mind the project is long and the team will need to sustain the schedule for the duration of the project. The best way to avoid extra hours is to stay on schedule and using the techniques and concepts in this post will assist any PM in this difficult task.
Minimize churn
Churn is defined as a couple of different things. One is reworking the same activity more than once. Clearly, we all plan to execute any activity only once so we need to stay with that as much as possible. This is where the concepts of baseline control come into play as both requirements and design changes in most development models cause rework and the subsequent sliding to the right of the schedule. Even in agile models where some element of churn is planned for, the project manager must monitor this and the movement of the activity to completion to ensure schedule achievement.
Secondly, churn is the technicians getting stuck on a particularly nasty problem. It could be connecting to other machines or processes or some complex logic that is not working properly. In all cases, I set a standard for technicians of the amount of time they should remain stuck on a problem before getting another set of eyes or a support organization involved to assist.
Most technicians are highly professional and pride themselves on their capabilities to solve problems. I treasure the spirit of these individuals but ask them to seek assistance. This is also easier if a 2 person development model is accepted as the help is inherently present. Obviously, if a technician is stuck on a problem, their estimates and actual time to complete an activity can be driven far out from planned which again impacts the overall schedule. Getting them assistance once the nasty issue is identified is important for the project manager.
Deadline Accountability
Staying on schedule is not just the responsibility of the project manager. The individuals doing the work also have responsibility for their individual tasks to ensure they are completed within the duration the technicians define. This naturally implies the technicians are consulted on the duration and not pushed into agreeing to task durations that are not achievable.
I typically see this come into play when a top down schedule is defined and the project manager has to fit all the tasks into a pre-defined timeframe. Many of these top down schedules are set by legitimate business needs and can be appropriate. Where the project manager can stray is to get an estimate from a technician that is for example 2 weeks and the PM push the technician into a 1 week duration. Overly long durations are also not appropriate but a reasonable agreement by both parties on the duration is most successful. Once the duration is agreed upon, holding the technician to this deadline is both appropriate and helpful to keeping the overall schedule on track.
Going back to the critical path padding, the PM really only needs to push on the critical path activities and not the ones with float. It is also my experience when the PM gets front loads activities and minimizes the pressure on the technician, the activities many times come in ahead of schedule. This cooperative and healthy working environment feeds mutual respect and success. It also gives the PM chips to play when a little extra effort is needed or the PM is in a bind and needs an extraordinary effort to stay on schedule.
This leads to a concept I call "Mini Crisis." As intermediate deadlines approach, these deadlines need to be highlighted by the PM and made visible to the project team. For example, if the development is to be completed by next Friday this should be visible to the project team at least a week ahead of time so all parties know of the deadline. If the team is falling behind, this may be an appropriate time to call is some chips, ask for extra effort, or even weekend work.
By pushing for and meeting these intermediate milestones, the PM maintains a position whereby the normal work schedule is maintained, technicians remains productive and the schedule stays on track. The tendency is to allow each to slip a day or two. As the one and two day slips add up, the schedule begins to slip by a week or two at a time. This precedent can overtake the culture on the project and lead to circumstances of a perception the schedule does not matter. So when intermediate deadlines are in jeopardy, I will create a crisis to achieve the milestone. By using the intermediate milestones, the crisis can be overcome in a much shorter timeframe enabling the team to get back on a normal work schedule. The side effect of overcoming a crisis can be a closer project team that is better able to handle larger crises if they occur.
Minimize Distractions
In many situations, PMs will allow multiple types of distractions to enter an otherwise healthy project environment. These distractions are more intrusive when a technician is executing a very complex or technical task and just needs to focus. I call this "heads down" and is when a technician focuses exclusively on the task at hand and ignores everything else. They may ignore email, phones calls, instant messages, etc. Allowing technicians at times to go "heads down" is something the technicians will greatly appreciate and provide a better solution in less time.
Other distractions can be management that is currently unhappy or a customer that is nervous. Most technicians "just want to do their work." The PMs that can screen the distractions from the technicians will see better results faster. These distractions can also be expense report approval timeliness, updating back office applications so email does not hit their inboxes, etc. Anything that takes them away from "just doing their work" is important for the PM to focus attention on as it offers the best opportunity to meet individual milestones and therefore the overall schedule.
Meetings are a constant source of frustration for technicians especially status meetings. How many of us have sat through meetings where all parties talk about their individual work while someone updates a project plan? Of course, updating the project plan is important from a monitoring standpoint but having everyone in a room for even one hour a week is a big drain on resources and capacity.
Other meeting such as reviews of requirements or design should only include those technicians who will have input into the decision. Many PMs like to have everyone in the room during discussions so that everyone feels involved and has input. This is rarely the case. Most technicians can make their inputs to a senior technician then get the output in a five minute discussion. The other 55 minutes is spent working on their tasks.
To get status, I ask the technicians carbon copy me on email pertaining to the deliverables. In larger project teams, these tend to be distribution lists so adding me is a one time activity. This enables me to both monitor progress and identify difficult or complex issues, but also get the status so I do not conduct status meetings.
The last distraction is admin like time sheets, expense reports, forms from finance or human resources. It gets back to just doing their work. These distractions eat up a great deal of time even though many are necessary. Find ways to minimize the admin workload. When traveling, I used to buy lunch and dinner for the team every day. This reduced the number of lines on the teams expense reports so less admin. Having lunch together also allowed me to fill in any holes about project status or address concerns the team might have. If forms needed to be filled out like for network access or physical access, I handled this. Compiling lists, etc are all examples of administrative tasks that are necessary but if executed by the PM enable the technicians to focus on the work.
Time off
Everyone needs a break. This includes evenings, weekends, and especially vacation/holidays. Sometimes it is difficult to find time to let people have blocks of time off but they need it. Work out summer vacations early so the project impact can be minimized and project coverage can be maintained. Protect their time off especially when they are meeting their deadlines. My only exception is when they miss an intermediate milestone (the mini-crisis) from above. Stellar performers will complete their work on time and with a sustainanble work pace will provide the backbone to a project team that meets their schedules.
Strong baseline control
Maintaining stability and control of the technical baselines is always a critical component to staying on schedule. This topic has been addressed by many smarter people before me so I will refer each of you to those other works.
In conclusion, many of the topics discussed speak to non-technical aspects of the project and in particular managing the people. Many PMs forget the people on the project team and their pivotal role in the success. No PM has ever completed a project without their staff so providing a healthy work environment for the staff and keeping them productive is something that should remain in the forefront of the PM. Naturally, the technical aspects have to remain covered as well. Using the techniques above will assist a PM in staying on schedule and out of the RED project scenarios.
Comments