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

Running before you Crawl

For many projects today, the end dates of the project are set before the project begins.  This date may be due to an internal company event such as the high selling season for a retailer or any external event such as a national or international conference where the results of a project are presented.  In both cases, the projects start with a hard schedule constraint date.  In many cases, the setting of this date is a management technique intended to motivate the project team to deliver within a designed timeframe.

At the outset of the project, the project manager works with the team and defines the project plan.  This plan could be in a project management tool and follow a waterfall like methodology or an agile tool where sprints or iterations are defined.  Given the end date constraint, the plan contains intermediate milestones to define progress with the project manager tracking and reporting on this progress.  In some cases, the intermediate milestones get pressure and some may slip out to the right.  Assuming the milestones are on the critical path, the launch or go-live date also begins to slip but with the hard completion date it cannot.

In these situations, we begin to get schedule compression with the project manager reporting the slippage and anxiety begins to grow.  As the anxiety and schedule pressure builds, people look for creative ways to keep the project moving so the completion date holds.  One of the so called creative ways is to move forward with the next phase of the project while the previous phase continues.  Sometimes this is justified as more parallel work or because the schedule says the project should move forward at this date.  Where this is most seen is the transition between finishing up development and a formal test phase like User Acceptance Testing (UAT).

When projects attempt to Run before They Crawl, the project spirals downward.  How often do we heard of projects with hundreds of critical bugs in UAT or ones where the test phase takes months to complete and was scheduled for 2-4 weeks.  These are instances that for sake of schedule, the project artificially moves forward before it is ready.  Running before you Crawl is a common cause of RED projects and dissatisfied customers.

We all know that hard end dates for projects abet undesired are a part of this profession.  We work to minimize the number of instances of this occurring but we all have to work within these boundaries especially when our customers need us to meet dates.  So how do we prevent running before we crawl?

For me, it comes down to effective planning and monitoring from the outset of the project, the first day.  Getting a solid project plan whether it is waterfall, agile, Six Sigma, or any methodology or hybrid is essential the first week.  As a consultant, I usually have an initial draft for customer review at the kickoff meeting.  Knowing full well the plan does not include customer tasks and will be modified but having it available first thing sets the stage for the project as a whole.

In this plan, there should be incremental milestones that have demonstrable product as a deliverable.  The agile and iterative methodologies have this built into each sprint.  The emerging product is shown to the customer to both relieve anxiety but also push the development team.  The teams should have a deployable product at the end of each sprint.  The astute project manager will also front load the critical and end to end functionality.  If the project is eCommerce, front load the interfaces to Order Management and Product Lifecycle Management (PLM) as well as the product search, CART, and Checkout functionality.  Having an end to end working solution even if just the absolute basics, positions the project and customer to succeed.  If the other functionality begins to slide to the right, the customer management has a viable choice of how much functionality is needed to meet the deadline.  This is a far better position than having extensive product searching or promotions functionality without the capability to purchase.

With each incremental milestone that occurs, these milestones must be achieved.  All too often, we make the assertion the time can be made up later.  This is very rarely the case and a prudent PM will not take this assertion as a strategy.  Pushing to meeting each milestone can create friction in a project team, but once they understand that many smaller and shorter pushes are much easier than the enormous longer push that has a missed deadline hanging over it, the project team can get into a steady rhythm that makes everyone from the project team to the customer sponsors comfortable and happy.

By focusing on incremental milestones and setting a project culture that deadlines however small are not missed, the project teams are much happier and the projects are not put into a position of trying to run before they crawl.  Hard deadlines are a part of the Project Management profession even the ones that are externally imposed so we need to take measures at the project outset to ensuring the success of our customers.

Implementation Methodologies: Good or Bad?

Are implementation methodologies helpful to project success or a hindrance?  It depends on how the project manager executes the methodology, and adapts to the unique situations on each project, and how well the project conforms to the assumptions within the methodology.  I am a firm believer in the value of an implementation methodology having used them previously and developed several myself.  The methodologies are a good starting point for developing a project plan providing the project manager with:

1. Templates for all project deliverables that the consulting/contractor staff are familiar with thus eliminating the startup costs associated with training the team and agreeing internally on the format and content of deliverables.
2. A development methodology the staff is both trained in and is comfortable executing.
3. Checklists of tasks to consider within the context of the project.
4. Typical staffing profiles and associated task durations and dependencies.

These are just a few of the benefits of a methodology and all have a positive impact on project success.  These methodologies are also based on fundamental assumptions that many times get missed by project managers including:

1. The customer is familiar with and agreeable to the development model proposed.
2. The customer can support the customer staffing model with roles such as a  business analyst, testing leads, etc.
3. The customer is agreeable with and supportive of the set of deliverables defined.
4. The statement of work or project charter is compatible with the methodology.
5. Individual projects should adjust the tasks, durations, and staffing to fit the unique project needs.

The specific assumptions associated with each model are unique to each model so identifying the implicit assumptions inherent with any methodology becomes a key component in determining how to tailor the methodology to each unique project.  In my experience, few methodologies formally document their assumptions creating a situation whereby PMs must derive the assumptions.  The tailoring concept is also a key as we all know that each project has its own idiosyncrasies that we have to deal with.  When methodologies are treated as a “cookbook” and applied in the exact same manner for each customer, then they can be a detriment to the project.

By understanding the implicit assumptions behind a methodology and tailoring the methodology when 1 to all of these assumptions are not valid, the project manager can effectively leverage the strengths and mitigate any weaknesses of a methodology.

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.

 

Resuscitation for a Red Project Team

We have all had projects where the project team is virtually DEAD! The project is in a red status and the path out is not known thus the project team is likely demoralized, fighting among themselves, disorganized, etc.  They and the project are DEAD and need resuscitation.  So what is the IT equivalent of the defibrillator?

I believe focusing on three main areas to revive the project team:

1. Team Composition and Dynamics
2. Fix Strategic Process/Methodology Issues
3. Regain Momentum on the Project Deliverables

Team Composition and Dynamics

The key element is assessing and understanding the mental state of the project team and address the findings.  Are they demoralized, fighting among themselves, lacking key skills on the team?  In my experience, the teams are usually behind and beginning to question their own skills and their capability to complete the project.  Although this may be true the team lacks key skills or certain individuals are creating an environment that is not conducive to project success (Fire the Bastards from Todd Williams), the situations tend to be multi-dimensional so team composition and dynamics is a beginning point.

In these situations, I bring renewed energy and confidence to the project reassuring the team that we can dig ourselves out of the hole.  This is the old school pep talk and is a good beginning.  The PM should pay close attention to how the team reacts as not all individuals react positively to the old school pep talk and the approach may need to be more individualized.  Also refocus on the future as the past is behind us and all we can control is how we perform from this point forward.  We should learn from the mistakes of the past but not dwell on what we did not previously produce but focus on what and how we will produce in the coming weeks.

Todd Williams (@BackFromRed) and I were discussing the last piece of this puzzle is to help them understand the PM is working for them (Does the PM work for the resources?), we are all on the same team and will only succeed as a team. This will provide additional confidence they can succeed from this point.  Congratulate them with each new achievement going forward.  I will discuss how to implement this in the coming paragraphs.  Focus on their individual confidence, team dynamics, and build them up as the project begins to gain momentum.

Fix Strategic Process/Methodology Issues

The reasons for a project going RED are typically at multiple levels and in several different areas.  One of those areas may be the strategy, methodology, or processes the project team is following during the project.  One project I inherited had 350 critical issues open when I arrived.  This was due to the lack of requirements at any level.  We were developing a system with extensive business logic but none of the logic was determined ahead of time and it was being determined as each new scenario was uncovered.  After six months of trying, we had 2500 issues total, 350 open issues and the business logic was stepping over itself.  We had a process issue and needed to define the business logic.  After spending two weeks documenting the business logic, it was all working 3 weeks later....

Build strategy is also a typical culprit.  I am currently working on a commercial software implementation of an order management and fulfillment system where the customer wants to convert all the configuration data the week before the User Acceptance Test (UAT).  This conversion data includes the production stores, distribution centers, delivery vehicles, etc.  Essentially all the critical configuration data will be converted and tested only during the UAT.  The end users will test if the proper stores are being served by the proper distribution centers and the trucks are serving the right delivery addresses.  The major UAT objective and critical business functions will only be reviewed in context during the UAT and not before.  This is clearly a flawed strategy.  The explanation is the conversion should occur at the end because it changes.  PMs should look strategically at the approach to building the system and look for issues such as noted above.

Finally, develop a plan for recovering the project.  This plan may include fixing issues such as noted above and other issues noted during the initial analysis.  As the plan begins to become clear, involve the project team in the plan before finalizing and include at least some of their feedback.  This will reinforce the premise that the PM works for the resources and builds confidence with the team as their concerns are being heard and addressed. This same plan is typically the topic of executive level briefings on the project so serves two purposes.

Gaining/regaining momentum on the project deliverables

Regain the project momentum is needed quickly and even during the timeframe when the other items above are in progress as the customer is typically concerned and needs to see positive results.  The first step is to find some deliverable that is easy and quick to produce (i.e. low hanging fruit).  This should be a solution component as documents are nice but are not the solution being delivered.  I will dedicate a future post to this topic.  In the example above where I had 350 open issues, I chose a solution component with only 10 open issues and focused two resources on resolving the issues.  The resources sat next to the tester and worked directly together to finalize the solution component.  Two days later, the first component was working as reported by the tester. Quick win number 1!

Re-evaluate the current project plan to create small well defined solution components.  In the old days, we called them inch pebbles instead of milestones.  If it takes more than a week to produce the inch pebble, then break it into a smaller component.  In many cases, the size of the solution components can be an issue so staying vigilant with the component size is important until the team and customer confidence has been rebuilt.  Establish a reporting mechanism that documents the real progress being made so the renewed momentum is visible on a frequent basis.  Having the customer provide the input data is best as it eliminates issues around data accuracy or validity.

The final piece of regaining momentum is to evaluate and identify where all the project issues reside.  The PM should interview and collect information from all parties on where they see the issues.  This interviewing should be on an informal basis so the interviewees are more likely to open up.  This process will also dovetail with the processes and methodology component of resuscitating the team.

By using this three phased approach to resuscitating the project team, the PM dropped into the hole of a DEAD project team has the best opportunity to revive the team, the customer relationship and the project.

Rebuilding Customer Confidence in a Red Project

At times we all find ourselves with a red project or are brought into a project in order to recover it from a red status.  The circumstances for the project being this state may be varied but typically the customer confidence needs bolstering.  When projects deteriorate into a red status, customer's confidence in the project team, the software, etc are usually diminished due to the circumstances that resulted in the red status.  The question becomes how does the project manager regain that confidence so not only can the project recover but also the customer regains confidence the project will be successful.  The following paragraphs define several focus points for the project manager as they work the project back.

Identify issues

The starting point for the recovery is to identify the issue(s) that caused the red status.  Rarely is it a single issue that drove the project to this state and more typically a combination of issues.  The project manager should ensure all stake holders and influential members of the customer staff are interviewed and solicited for their thoughts.  This is an especially critical step when the project manager is new to the project as demonstrating the openness to the project team being part of the problem shows balance.

Besides the customer stakeholders, the PM should also interview the project team.  In many cases, this team's morale is depleted and having the opportunity to contribute is an initial step in getting their morale and ultimately productivity up to the needed levels.  Within both the project team and customer team, gaining consensus on the approach moving forward is an important gate.

Be prepared for some emotional discussion and having to weed through interpersonal conflicts.  The interviewing process will take some time as the need to vent in many individuals is also an initial step in assisting them to move forward.  The PM may identify people who will struggle to move forward so having their input better positions the PM when objections to the plans surface.  Getting to the root cause(s) is the main objective of this initial phase with providing a basis for emotional healing being secondary.

Tactical and strategic plans to recover

Once the root issues are identified and all parties are on the path to recovering emotionally, the PM must now get back to delivering the project.  The plan devised should have both strategic and tactical components.  The strategic elements are designed for the executive suite who are undoubtedly involved at this point.  As executives and especially business executives, the strategic plan must include elements on how to address the identified issues in terms and context appropriate for the senior executives.  For example, if a major issue is the number of open bugs in the system, this group will want to see a plan such as the number of bugs per week to be fixed and the timeline for getting back to a "normal" number.

The plan must also include tactical elements as the project team will need activities in which to execute on a daily basis.  Each project team member should understand their role and associated activities.  To continue the example above, each team member should understand the number of bugs per day they need to repair.  Obviously, the tactical plan must support the strategic plan so that the total number of bugs per day per person equals the strategic plan commitment of bugs per week.

Demonstrate value

For the PM, the most important element is to demonstrate value and a capability to fix the problem(s).  Whether the PM is new to the project or not, customer confidence will begin with the individual in charge and do they have the skills to identify the issues, build the recovery plans, and execute on those plans.  If the PM is not able to establish customer confidence in themselves, rebuilding customer confidence in the overall project team becomes a much more difficult endeavor.

This confidence building process must be quick due to the distress which the customer is likely feeling.  Quick and even subtle changes that address specific issues is a good way to begin to build that trust.  The PM can identify small changes to the project processes or team that show immediate value goes a long way toward building or rebuilding that trust.  The PM should demonstrate value in quantifiable terms as the customer will likely strongly challenge the PM when making changes especially if the changes are on the customer side.

Demonstrate moving forward

As the plan execution begins, quantifiable evidence of their success is essential.  This evidence can be in terms of the example where the team is repairing bugs at the rate committed or that functionality is being delivered unlike before.  The phase of the project will govern the quantifiable evidence most appropriate and all parties should agree upon metrics as part of the strategic plan.  These metrics including the evaluation methods and thresholds achieve both the goal of demonstrating progress but also show the team's and PM capability to deliver on commitments.

The PM should conduct at least weekly reviews of progress across all metrics areas and more frequently for the staff reporting to the executives.  In cases of consulting or contracting companies working for a customer, having the customer team report the findings is also important for building confidence as it eliminates any perceptions of impropriety.  Keep the meetings short, open, and factual.  Even when the project team misses a deadline, this transparency by the PM will actually build confidence in the PM so provide the project team additional time to achieve the technical objectives.

Keep in mind but stay away from SOW

Although the Statement of Work (SOW) governs the work on the project, PMs should be very careful before pulling the out of scope card.  At this point, keeping the customer is typically the most important objective so focusing on strategic and tactical plan execution and demonstrating forward progress are more important.  If the situation contractually becomes dire, the PM should weigh the chances of project cancellation with the contract provisions in question.  Certainly, the management of the PM should be consulted before taking this measure.

When projects go red, regaining customer confidence is an important initial step with the PM as the lead in this rebuilding effort.  The steps and approaches noted above provide the PM with some guidelines and objectives as they work through recovering the project.  Gaining the confidence of the customer in the PM can assist the project team and lends credibility as the project team executes the strategic and tactical plans created.  Consensus both within the customer and project teams is essential so all parties are aligned when the empirical data is returned.  Incremental and steady progress back from the brink will both rebuild the customer confidence and recover the project.

Have multiple releases?: A different approach to maintaining the branches.

Have you been in a operational environment where multiple development streams each with unique functionality are in development but the release to production dates are not in a definitive sequence.  Or perhaps, an incremental release development model where the development is broken into blocks that are larger than any sprint/iteration.  These are examples of the scenarios whereby the question of when to merge the development in the configuration management tool branch becomes an acute question.  The timing of the merge to the trunk places the operations or project manager in a position whereby the production environment cannot be updated until the new functionality is also deployed.  This becomes an increasingly acute problem when the number of changes in production is higher, of high priority, or the size of the new functional release increases as the regression test cycle is necessarily longer.  So how do we solve this problem?

Traditionally, we have merged the branches to the trunk and built our pre production testing environment from the trunk which creates the circumstances noted above.  I suggest reversing that model.

As changes are made in the trunk (production) merge those changes out to the branch(s).  This creates in the branch(s) a code baseline that is identical to the future production environment and relieves the need to know definitively the order in which the branch(s) will be deployed to production.  It also creates in the branch a code baseline that is identical to the future production state but is in the branch and not the trunk so the capability to update production with either high priority fixes or any other branch remains.  In this instance, the issues associated with merging of the new functionality to the production baseline are flushed out in the branch by building the pre-production testing environments from the branch and testing. 

Once the functionality is flushed out in the branch and this branch is determined to be the next going to production, then the branch is merged to the trunk, regression testing and release to production occur.  By testing out in the branch, the regression testing from the trunk (after the merge) is greatly reduced thus minimising the risk of production maintenance during the regression testing window.  The positive side effect is the decision on which new functional release will go to production is delayed until after the functional testing in the branch and easing any decisions in this area.

The downside to this approach is more maintenance of code out in the branches.  The decision becomes a trade-off between the risks associated with longer regression test cycles and the inability to maintain production during this cycle with the additional effort associated with maintaining the branches.  In those circumstances where there are a lot of high priority updates in production and/or the new releases are large, numerous, or have long regression test cycles, I suggest considering this alternative approach.

Do we need a stabilization period?

Over time the concept of a post go-live stabilization period has emerged.  For many companies, this is a period of time after deploying a new major release to production where previously unknown issues are identified and rectified.  Additionally, end users spend a period of time becoming proficient in the new release and eventually become comfortable as both the technology matures and their knowledge and comfort levels stabilize.

These periods have become the norm since "it just seems to work out that way."  As we project managers have deployed a few net new implementations or major releases, it seems this period is inevitable.  The project teams have done their due dilligence in design, building, and testing but inveritably there are issues either technical or functional that are always found after the deployment.  We have done our best and "it is what it is."  We find a previously unseen path in a business process or an additional value in a status dropdown menu.  Perhaps, we also identify an end user who needs additional training in the execution of a particular business process.  It could even be an overnight batch job that runs longer on the last Sunday of the month due to other software jobs running at the same time causing operational issues.

This leads us to a fundamental question.  Are stabilization periods merely an inevitable part of a software deployment or are they indicators that we project managers have areas of our planning and risk assessments on which we could improve?  As touched on above, the stabilization can occur in either technology or functional areas or both.  Let's examine some ideas on how to reduce or eliminate the need for a stabilization period.

As project managers, one of our fundamental tasks is to assess risk, manage risk, and build project plans that minimize the risk profile.  Below are a series of thoughts and concepts to minimize these risks and improve our project plans with the intent of minimizing or even eliminating the need for a stabilization period. 

The first set of ideas takes the concept of a BETA testing period and moves it to the left.  With BETA testing, project managers will typically deploy the solution to a small subset of users and enable them to operate the solution under true production conditions.  These conditions use production data, real life business processes, address real life scenarios including all edge cases, as well as address user interface design and ease of use.

Free Form User Acceptance Testing

In most projects, we will define a set of test cases for testers to execute.  We measure the completion percentages, define exit criteria for completion of the test phase, and base our completion decisions on quantitative data.  These are all good things as they provide us a firm factual basis for making our deployment decisions.  These techniques are a fundamental part of our projects and should remain so.  What I am advocating is an extension beyond traditional UAT.  The issues arise when we assume our use cases or test cases represent 100% of the scenarios the solution is designed to address.  Although this is the goal, most project teams find this a very difficult task to achieve.  Even with dedicated test teams, the task is challenging.

In a BETA testing period or stabilization period, the testers are free to execute any business process, address any scenario, and use any set of keystrokes imaginable.  This is truly representative of the production environment since the users will not have defined keystrokes to address every production scenario.  What would happen if we defined a second phase of the UAT to be a free form period?  We could encourage the testers to execute their daily work since it is this work where the edge cases will be identified.  Given the scenarios are randomized, the testers also get the added benefit of getting beyond scripts and are required to truly understand the software and become proficient with it but in an environment and timing that does not impact production work.

Effectively, what this does is move the "stabilization period" back into the project where we can plan and monitor its progress.  The number and severity of errors will become known over time so the duration of this second phase can be difficult to pre plan.  The advantage to this technique is we uncover and repair any errors in a test environment and not in a production environment where the business impact is much greater.

Run batch jobs in production once confirmed functional

In projects that are net new implementations, we can extend this same concept to any interfaces we build.  The main issues with new interfaces are typically three fold: 1) interaction with other batch processes, 2) data moving from one system to another, and 3) target system functioning properly with data from source system.

During the course of our projects, we will build interfaces that both maintain lookup data like products in a eCommerce solution or transactional data like leads sources in a CRM solution.  In each of these instances, unforeseen edge cases can arise and we would like to catch and repair issues associated with these cases.  So let's move this identification process to the left and back within the product schedule where we can better manage the uncertainty.

As the interfaces are built, turn them on and let them run.  If the eCommerce solution has a daily update of products from a PLM solution, turn it on and let it run each night.  Over the course of the rest of the development, this interface will run enabling both the technicians monitoring the interface to become accustomed to it running, will catch any errors resulting from edge cases enabling the project team to fix them, and will identify any unusual run times and make the needed adjustments. All of this is done before the solution is in production enabling the project manager the time to appropriately plan and schedule the repair activities.

For interfaces such as lead generation and especially in cases where manual steps like pointing to a lead file are required, the administrators and even the end users have more opportunties to become proficient in the mechanics of uploading the file for example so are more proficient long before the solution goes to production.

The above concepts are driven by moving the stabilization activities to the left back into the project.  The next three concepts address how we can improve the identification of those cases normally found by free form testing and ideally identify them in the early stages.  Even with the techniques above, the project manager must address unforeseen development activities that can impact the project timeline.  Identifying these cases during the planning cycles enables a more complete project plan.

Testing that simulates real world

Since we started the examination of concepts beginning with production and working back to the project beginning, let's continue this approach and address the formal test phases.  What can we do here to improve our testing.

The fundamental premise of testing is to create or recreate the production scenarios so our project teams can identify and repair the issues eventually leading to the satisfaction of all business requirements or use cases.  This remains a good objective but we can augment that objective by examining how we both structure the test cases and execute them in the context that more closely resembles the actual production environment.

Let's look at an example of a solution for financials.  In this example, the solution includes a wide variety of business modules including Accounts Payable, Accounts Receivable, General Ledger, Billing, and Purchasing.  In examining these modules as a set, they have a monthly rhythm as companies close the books monthly and define financial reports on a monthly basis that roll up into quarterly reports.  If a public company, the quarterly reporting includes SEC reporting.  Quarterly reports roll up into annual reports.

Could we structure the testing of a system like this to simulate a years worth of activity?  The test period itself would be much smaller than a year but we could define a month as a week of testing.  So week 1 of testing would translate into the first production month.  Close the books on Friday and start the second month at the beginning of the next week.  This would enable the test team to execute all the test cases associated with purchasing materials, receive the invoice, perform all required matching, cut the check from AP, then post the journals to GL and close the books at the end of the month.  The same concept applies to the invoicing and AR side.  Some purchases or invoices would remain in AP or AR until the next month as would naturally occur in production.

With this same technique, the quarterly reports and SEC filings could be executed and eventually annual reports.  Having this in context both exercises the system through an entire year but also assists the end users in thinking through all aspects of the process as it is not within the context of software requirements but in the context of their every day jobs of which they are far more familiar.

Naturally as the issues are identified, the project team would prioritize and repair them.  By structuring the testing within a more functional context, the project manager can achieve a production simulation that more closely represents what would happen during the "stabilization" period.

Can we also test the beginning of the business process first?  For example, lead generation and processing begins with the generation or loading of leads before proceeding to lead assignment, then working the leads and creating opportunities, etc.  If we flush out the lead generation functionality first as each subsequent sub process like lead assignment is developed we will naturally test the lead generation then lead assignment.  The software will dictate we add leads before we assign them so the initial sub processes are continually regression tested as each sub process in the entire business process is added.  Combine this will using production data and we are now continually regression testing previous builds, verifying edge cases by using production data, and minimizing the defect detection risks inherent in formal testing.

This leads us to the last two concepts which stem from how can we improve the initial set of test cases.

Business process flows that lead to use cases

The key to better test cases in my experience is getting two sets of people involved at the outset of the project.  The first is actual users of the system.  Typically, our project teams will ask the business users for their requirements or use cases and anticipate the resulting list of items will be complete and accurate.  In my experience, this is a difficult question for a business user to answer because it is not within a context the business user typically works and thinks.

If we ask the question in the context of the business user, we can anticipate a better and more complete response.  I like the use of business process flows as a predecessor to use and test cases.  We ask the business user what activities do they perform on a typical day. Yesterday can be a great start or what did you do last week.  It starts with the day to day activities and moves into the more unusual cases that we would call edge cases.  Document the activities within a business process flow as this both defines a good mechanism to extract use cases but also provides a mechanism for defining alternate flows and negative cases.

When we reach a decision point, there must be a yes and no patch.  Remembering to come back to the less traveled path may be difficult but stands out in a process flow.  It also spurs us to ask the question "what if that does not occur." The business process flows enable our project teams to be more systematic in our investigation and documentation of the requirements.  By being systematic, we can collect a higher percentage of the actual cases that will be observed in production.

Testers involved in defining edge and negative cases

As a supplement to this process and if a dedicated test team is available, these individuals should be involved from the beginning of the process.  Testers by nature tend to be detailed people who are adept at finding both the edge and negative cases.  Dedicated test teams also tend to have good relationships with the business users so they will feed off each other as they collectively think through how the business operates.  Both of these dynamics are positive for the project manager as the end result is a more complete and detailed set of use cases or requirements from which the plan is planned.

If we follow stricter and more structured quality assurance and testing techniques, the length of stabilization periods become far less than previously experienced and may even become negligible. Thinking through the reasons for stabilization periods and structuring our project plans to minimize these risks enables project managers to have smoother running projects and minimize or eliminate the need for stabilization periods.

Pricing based on effort or duration

As a precursor to consulting engagements, project managers are commonly asked to price their projects.  But how does one go about pricing a consulting engagement?  A common method of pricing is to collect a set of requirements or use cases and collaborate with the individuals who will perform the work.  From this collaboration comes an estimated time per requirement or use case.  All of this is a good starting point for pricing.

 

Typically, the next step is to add up all the hours, multiply by the rate(s) of the resources and calculate a price figure.  The calculations become more complicated if there are multiple rates, time for testing, project management, and perhaps start up time are added, but one key point, I believe, is missing with this approach.

 

As project managers, we have all developed a project plan complete with our work breakdown structure (WBS), resources, and dependencies.  It is these dependencies and the resulting float or slack that drives the fundamental question for this post.  The above approach to pricing implicitly assumes that each resource is utilized 100%, a logical assumption and goal.  But we all know that each project has some float/slack in it so all resources spend some time outside of the effort defined in the estimates and are, therefore, not utilized 100%.  This additional time consumes budget and rightfully so.  The concept of the PERT chart was developed to both highlight and calculate this float. 

 

This is not to say that resources are at times unproductive but they work on items that are not explicitly defined as their task during the times of float/slack.  For more senior resources, this can be assisting less experienced resources.  Cases can be made to begin a dependent task before the predecessor is complete.  Even in those circumstances where all tasks with float are started as their early start dates, these periods of float/slack continue to exist which moves us away from the 100% utilization implicit assumption.  This leads me to the conclusion that consultants should base pricing on duration and not effort.

 

So what do about this since the amount of float on any project is different?  We left off above with detailed estimates of either requirements or use cases that were defined by the individual doing the work that remains a good starting point.  From this starting point, defining the project schedule is the next step as it will have all the WBS dependencies, define the float for this project, and the timing of when resources are staffed and rolled off the project.  From here, I develop a project budget by laying down the staffing plan that defines on a week by week basis what resources are required on a project using the project schedule as basis for which resources are needed at any particular point.  Typically, I use a spreadsheet application to calculate on a weekly basis the cost of each resource, then sum the weekly amounts for a project budget and therefore price.

 

The above approach assumes consultants are 100% dedicated to a project that is almost but not always true.  In instances where multiple projects are utilizing the same staff, moving resources between projects will minimize the differences between pricing based on effort and duration.  In most consulting engagements, this proves difficult so the duration based approach has worked well for me.

 

Requirements: Are they a necessary part of a software project?

Historically, we have taken the approach of developing requirements through many different mechanisms.  We may ask the customer for an initial set.  We may conduct Joint Application Design (JAD) sessions where we conduct meetings for multiple days to extract requirements from our customers.  These techniques and many others remain a central part of many software development and implementation projects today.  Are these techniques still central to the process?

In the late 80's and early 90's, we began to see an interesting dynamic occuring.  When asking our customers for their requirements, a couple of results were commonly seen:

• The customers knew how their current system worked but had difficulty articulating what the requirements were and in particular identifying all the requirements.  Articulating all the system features was not something they thought about or did everyday so asking them was/is a very difficult task.
• The customers also tended to describe their current system and what it did as opposed to what the business needed the system to do.  Customers know their current system so a natural place to start was articulating how they used their current system, a logical conclusion but one that tended to design the solution including potentially unnecessary customizations in commercial software.

The common end result of these sessions was a set of features that did not meet what the customer needed and in many cases were just a subset of what the system needed to do.  Lay on top the duration of the activity and length of time to develop resulted in requirements changes and utlimately a dissatisfied customer as the solution did not meet the business needs at the time of production deployment.  The end result was projects going overtime and budget due to scope creep from the project team's perspective but necessary features from the business perspective.  Both positions were fair and justified.

As these dynamics became apparent, we began to develop several tenants that remain true today.

• Customers have a greater capability to describe what is needed when looking at a prototype of the solution or at least business processes.  Business Processing Re-engineering (BPR) has been around a long time and is not as prevalent as it used to be.
• Customers have a greater capability describing what they do on a daily basis and even infrequently.
• Working or partially working software is a better tool for understanding what a solution needs to do than any form of documentation.

This has lead us down a path where use cases and/or user stories have become a legitimate mechanism for defining what a system must do.  The prototyping techniques and now the agile methodologies all expouse this mechanism as a favored way to define the scope of a project.  Combine this with business processing modeling and the project manager has a different tool to define the "What" of the system.  Process modeling and use cases also provide four additional benefits:

• Is more systematic as the team's tend to look at all paths and not just the happy path.  In a process model, a decision point must have a Yes and No path to the question.  In many questions, one or the other is an edge case so can be overlooked when reviewing just use cases. Modeling has an inherent auditing capability that tends to drive more thoroughness.
• Provides a mechanism to look for process improvements.  In many cases and once the process is defined, customers can more easily identify steps or decision points that are no longer needed or can be streamlined.
• Is agnostic of the legacy application which enables the project team to define a design or configuration for commercial software unburdened by the legacy system.  For commercial software, this is particularly useful in working within a core product and avoiding costly customizations.
• Provides a better mechanism for the test teams to become involved earlier in the project.  When developing requirements, many test teams opt to review the session output and do not contribute to the requirements development.  By using modeling and use cases when the use cases drive the structure and scope of the testing, the testing teams are motivated to participate early.  The test team also provide a valuable service as they tend to be very systematic in thinking through edge cases and error scenarios resulting in a more complete set of use cases or process flows.

In summary, defining "what" the system needs to do remains a critical part of a project.  As we have evolved, how we define "what" has more options that now include business process modeling, use case or user story definitions, and prototypes as a substitute for requirements gathering.  When beginning a project, considering the appropriate mechanism for defining scope is an early and critical project management decision.

These mechanisms have different advantages depending on whether the project is a consulting project with a scope based statement of work whether it be a custom development or commercial software implementation or a product development organization developing and improving a commercial product for sale.    These pros and cons of these techniques with respect to the project type are a topic for a future post.

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.