Mark Gibson; PgMP, PMP, IBM certified Executive Project Manager

Does Project Planning consist of a project plan?

In nearly all projects these days, project managers produce a project plan consisting of the work breakdown structure, resourcing, etc. Does the process begin and end with this plan? Many people would say the plan is the beginning and as events unfold this plan is updated with status, revised to address issues that arise, and ultimately completed. I would agree with this notion but suggest the project plan is not the first planning deliverable. It needs input not only for the work breakdown structure but also from other sources. These sources include those management processes that underly all of our projects.

In my projects, I produce a deliverable originally called a Project Infrastructure Document from my days at PeopleSoft to now a Program Management Plan. Each term is a good description as the infrastructure of say a house begins with the foundation. The same applies to projects or programs. So what are the foundation management processes and policies underpinning all projects? They include at a minimum:

• Communications Plan – defines the type, format and timing of all internal and external information dissemination about the program.

• Quality Assurance Plan – defines the use and timing of any quality assurance functions that can include, but may not be limited to, design and code reviews, milestone reviews, and metrics.

• Risk Management Plan – identifies any risks to technical or business goals, identifies the impact of the risk, likelihood of occurrence, and documents mitigation plans.

• Education Strategy and Plan – defines the manner and mechanisms by which individuals such as the technical staff and customer support staff will gain the necessary knowledge to effectively operate and sustain the developed solution.

• Testing Strategy – defines the types of testing required during the development, goals of each test phase, defines the drafting process for the test plans, and the process and tools required for testing.

• Configuration Management Plan - The configuration management plan defines those set of procedures to ensure that both the solution code and master data are maintained in a controlled fashion.

• Rollout Strategy/RoadMap– defines the relative timing and functionality deployed to production.

• Project Plan – baselined after completion of the first seven chapters, it pulls all aspects of the development into a consolidated execution plan. The project manager will update this plan periodically as solution requirements are finalized.

In addition to the chapters above, I have on occasion included project acceptance criteria, travel policies, and budget baselines when unique project conditions warrant a more formal documentation of these policies. By formalizing these processes and policies within an early deliverable, I am able to better assess and estimate the duration of activities which drive the schedule. For example, by understanding all the test phases, their objectives and who will execute the tests, the durations of each individual phase is better understood as well as the level of effort for my team. Imagine a circumstance when the PM is expecting a testing program that includes unit testing, system testing, and then a production decision but the customer is expecting a performance test phase and a user acceptance test phase in addition to the above. Including these additional test phases establishes a very different testing program and the associated schedule.

At a deeper level, consider differences in expectations around the objectives of each phase. I have experienced a customer that defined unit testing as the validation of the proper interaction of all solution components including interfaces, conversions, and use cases and with production like data. This definition is very different than most of us would expect and creates a different set of activities, staffing, and durations. Or consider a project where the testing phases require all severity level 1 and 2 bugs be closed before proceeding to the next test phase. These are very typical criteria with typical defintions of the levels but what happens if the definition of a severity level 2 includes functionality with workarounds, the dynamic changes.

The project plan itself is included in the document as with many contracts, the project manager may want to formalize the initial plan as the baseline upon which statements of work and budgets are committed. Project plans by nature are living documents while contracts and budgets are not, so having a more formal baseline or starting project plan can prove valuable when schedules begin to move to the right and either financial or legal professionals begin to ask for the circumstances behind this schedule movement.

Based on our experiences, we each bring assumptions to the processes defined in each of the chapters above. Some of these assumptions are identified in the paragraphs above as well as other conflicting assumptions which I have personally experienced. Highlighting those assumptions in written form brings them to the forefront and enables discussions at the outset of the project. Differences in these assumptions can be discussed and reconciled long before they have a negative impact to the project or cause anxiety between counterparts.

The program management plan has enabled me to remove or minimize risks of these circumstances occurring. The biggest challenge is taking the time early in the project to discuss and reconcile the details of these processes vice waiting until issues or misunderstandings occur.

Leadership under Stress

In my recent post Lead from the front or back, the topic of leading from the front or back was discussed. Although leading from the back is the preferred approach in most instances, times do occur when the project manager is needed at the front. These times include the days just prior to going live, when schedules are not being met, or even when technicians are struggling with a task. So what is different about leading from the front? I think there are four differences when leading from the front and especially in high stress situations.

Increase communication and coordination

The tendency of people when operating is high stress situations are two-fold: 1) they focus exclusively on the task at hand. This is a good thing if the resource is a technician and needs to complete a critical task, but can cause disruption if someone is not coordinating the activities. 2) they become overwhelmed with all the activities and bounce between different activities and are unable to complete any of them.

When these situations arise, they are characterized by a large number of activities that need to occur in tight succession across many different teams and within a very tight timetable. The few days before going live are a typical example when conversions are running and one needs to start immediately after a previous conversion has concluded, additional setup needs to occur, network connection verification is occurring at the same time, then security verification, final builds and final testing prior to turning on the switch. The amount of activity requires both an increased level of coordination as well as communication and is perfectly suited for the project manager to step into this role.

By increasing the coordination and specifically this does NOT mean more meetings but managing by walking around. The project manager should get on the phone or walk to the desk of the people who are executing the tasks and minimize the use of email, texts and all non face to face communication. These other mechanisms are slower when speed is of the essence. By seeing the resources face to face, the project manager can also gauge when resources are becoming overwhelmed with all the activity and provides an opportunity to both brief the resources on the progress and encourage them.

Finally, the project manager should find a mechanism to keep senior management informed of the progress. I will typically do this in two ways: 1) provide a summary level status on something like a spreadsheet, wiki, or project website so the executives can look for and review status when time allows, 2) spend 5 minutes each day to brief at least the sponsors on the progress. This briefing will include the tasks completed, a summary of on schedule status, any challenges, and what activities are next.

Define discreet objectives

The activities given to technicians at this point should be very discreet and well defined. In the non-stressful situations when leading from the back, providing technicians more general guidance provided them a way to be creative and use their problem solving skills. When in stressful situations, this can work against the project manager as that creativity may not sync up with the creativity of other technicians.

In these instances, a very defined tasks such as open port 8081 on the web servers, execute the conversion script for loading customers, or update the application server with code base 1.2.2. This level of tasking ensures the synchronization of all resources and minimizes the chances of activities getting out of sync. In most cases, such as going live, the activities were defined in detail previously and the technicians played the most significant role in defining the activities. When the stressful time begins is when the project manager can take over and lead from the front. 

Take care of technicians first

In these situations when a large number of activities are occurring either in succession or simultaneously, there is a natural conflict in managing the project manager's time executing their assigned activities and managing the activities of the project team resources. Time becomes short and there are times when the project manager needs to chose between executing their tasks and supporting the technicians. In these instances, I always support the technicians. Why is a question that may come to mind?

The most important people in getting a new solution live or in stressful situations are the project team members! The project manager can help with planning, coordination and many other tasks but the technicians and functional business resources are the ones that make it happen. In the case of going live, the planning is done and the team is executing at that point and the people who execute the plans are the technicians and functional business users.

In these situations, the project team will be stressed out. They are being pushed from all directions. When situations occur where the project manager is pushing the resource and the resource needs help, the project manager needs to help them first. Let's look at the opposite situation... The PM is pushing the technician to finish a critical task, the technician needs help but the PM goes off to update a status report or some other task on the plate of the PM. How does the PM look in that situation? The PM is pushing but won't help when it is needed. The PM loses credibility with the technician.... the urgency is no longer there... Not a good situation. Even when the PM task is to brief an executive, the PM should help the technician after calling the executive and explaining of course. In my experience, I have seen very few executives who do not want to see the work completed first before they are briefed and especially in high stress situations.

Eliminate distractions

Distractions are a constant sources of schedule delays and a non-productive consumer of capacity. The level and number of distractions can increase dramatically in high stress situations as some resources become overwhelmed with the situation, become uncomfortable with a previously agreed upon plan, or even begin to consume other resources.

In the case of going live, the easiest way to eliminate distractions is to develop a go-live plan before the actual date of going live. I routinely execute dry runs of the plan to both identify errors and create an increased comfort level. In situations where schedules have been breached, this option is not always available so communicating and coordinating with also help to minimize the distractions.

When the time does come when the project manager must lead from the front, the concepts above will assist each of us in working through that high stress situation.

How to stay on Schedule

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.

 

Education Strategies for Enterprise Software Implementations - Part 2

In the initial post of this series, we discussed the use of formal classroom training and its value in the education strategies for commercial software implementations.  In this second and final post, we will review the opportunities later in the project and the opportunities intrinsic to certain methodologies.

Formal Demonstration

After formal training, the requirements definition or gathering process can begin.  By using the formal training as the foundation, the customer team has a better understanding of the available options within the commercial package.  The project manager can reinforce the classroom training and supplement the requirements process by using the software to demonstrate and illustrate the functionality under discussion with the group.  This begins the transition from understanding the software in theory to understanding and collaborating with the implementation team on how best to configure the commercial software to the customer business.  The side benefit is increased acceptance of and understanding of the solution by the customer as they participate in and help to define the solution.

Prototyping

If a prototyping-based approach is chosen by the project manager, this affords good opportunities to integrate the training and development into a single activity.  Education on the screens and functionality will naturally occur when the end users define the solution operation.  The key is to use functional prototypes so the details of the screens are known vice demonstrating wire frames which leaves some doubt.  When implementing a commercial package, the focus is on the options available for configuration so the focus initially is more on the administration screens which govern the operation of the end user screens.  Once the available options are known and the mechanics of configuring, then the focus can shift to how the end user screens operate with any given configuration.  This process is iterative by nature so the knowledge is re-enforced of how to configure the commercial software to achieve a desired end user experience.

Testing

One of the final opportunities to educate the end users before the traditional pre-deployment training.  The initial testing phases including a traditional system test or user acceptance training afford chances to both flush out the details of the functionality but also reinforce what has been learned to date by exercising the features of the solution.  Besides the project team, this form of education can be expanded to other groups to increase the set of end users who are proficient in the solution.  This is especially important in a widely distributed set of sites or when the decision of acceptance is made by a group larger than the project team.  Similar to the prototyping approach, exercising the screens will naturally result in the accumulation of knowledge and proficiency on the solution.

Playground

Finally, the use of a training or playground environment is a traditional manner to educate customer on their emerging solution.  This environment is typically independent of any formal development or testing environment so the individuals looking for education are not impacted by the instability of the development and testing environments.  This also affords an environment for other traditional activities such as test planning.  When using a playground environment, it tends to be easier to provide some structure such as use cases or a test planning activity initially.  Once more proficiency is gained, the freedom to exercise the functionality in a more ad hoc fashion can be carefully managed.

The education opportunities defined in both part 1 and 2 of this post identify options for a project manager in either a custom development or commercial software implementation.  The use of any number of these suggestions is a project specific decision.

Other recent posts include:

PodCast: Interview on Resuscitating a Red Project Team

Anxious Customer: Options on what to do Part 1

Resuscitation of a Red Project Team

Have Multiple Releases: A Different Approach to Maintaining the Branches

Leadership Question: Does the PM work for the resources?

Podcast: Interview on Resuscitating a Red Project Team

After publishing this post, I received a request by Samad Aidane (@samadaidane) to expand upon the ideas and techniques described therein.  It also contains some additional ideas on the "Do Project Managers Work for the Resources" and "Basic Tenants for Project Management" posts. 

 This Interview on Resuscitating a Red Project Team was conducted on February 19th by Samad Aidane (Guerilla Project Manager Blog).  I hope you all enjoy.

Education Strategies for Commercial Software Implementations - Part 1

During any enterprise commercial software implementation, the project team should take steps to ensure the customer can operate and maintain the implementation after deployment and rolling off the vendor resources.  There are several considerations when determining how to accomplish this body of work including the organizational structure of the customer resources, the current knowledge level of the staff, and the existence or non-existence of any post production support contracts.  Once these questions are answered, the next set of questions entail identifying the sets of unique groups to be educated and the individuals in each group.

A quick side note:  I typically use the term education vice training as training has the connotation of a formal set of activities including a classroom, a trainer, slides and a formalized agenda.  Although, this activity has a part in educating people, I believe this is the beginning of educating people and not the end.  The paragraphs below identify additional opportunities to increase the knowledge level of customer personnel to the desired level.

1. Formal Classroom Training

• Use Vendor training first

Most commercial software vendors provide formal classroom training which is a good base level for individuals new to the software.  This also provides comprehensive coverage across the entire breadth of the available functionality. It is optimally attained very early in the project and prior to any significant requirements analysis activity to afford the customer resources application level context for the requirements discussions or sprints.  The vendor team gets discussions in more depth and additional resources to collaborate on the optimal solution.

• Use project team to conduct informal training.  Let customer drive the agenda. product documentation can be guide

In some situations, formal classroom training may be impractical for any number of reasons.  In these cases, the project manager can consider using experienced project team members to review the available functionality.  These formal sessions should focus on configuration options available and how these options impact business processes.  Typically, the product documentation can be used to provide a sort of agenda for this less formal training so the project team is not burdened with developing training material.  Given the project team’s understanding of the customer environment, this type of training is typically more focused on the project team’s understanding of the customer needs.  There is a balance point here between briefing functionality which may not be used versus providing more depth of functionality which will definitely be used.

As with formal classroom, this enables the customer to see how their needs can be met and the background to be a true partner in deciding the optimal solution.  A positive side effect is the beginning of getting familiar with any administration screens and a customer more committed to the defined solution since it was determined in a collaborative fashion. A second positive side effect is more predictable detailed design sessions for those PMs running models with defined requirements periods.  By having a more educated customer, there is less need to review how the system works since this was covered in the training.  This discussions typically become focused on discussing the pros and cons of a small set of alternative solutions or quick agreement on options with few options.  In either case, the discussion timeframe is more predicable affording the PM greater schedule control.

Part 2 of the series is now available.