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.

Lead from the front or the back

Earlier this week, I was watching the movie "Gladiator" for the nth time and how the Russell Crowe character lead his troops into the battle with Germania. He developed the strategy with his lieutenants, determined the points when new phases of the battle should begin such as when to unleash "Hell" and when the cavalry would engage which is personally lead. During the cavalry sequence, he lead from the front and was the person who made initial contact. The same is true of Mel Gibson in "BraveHeart" where he lead the infantry charge from the front. This started me thinking about leading from the front and back during software projects. Is it appropriate for a program and or project manager to lead from either the front or back and if so when.

In thinking about what I have done, sometimes I lead from the front but mostly the back. There are several circumstances that move me to the front and in this case leading from the front means rolling up my sleeves and doing the implementation or development work. This could be writing use/test cases during the initial stages of the project, working with business leaders to understand the business requirements or problems the program or project is intended to solve, understanding operational issues that have come to light, assisting with a particularly sticky technical problem.

In cases like working with the business leaders early in the project or analyzing operational issues, these seem to be mainstream activities for a program manager.  The liaison with the business frees up the technical staff to work through the solution itself as well as build and test it. Defining and breaking down business processes into use cases and test scenarios/cases also seems like an important activity to lead from the front but this is also when the PgM/PM begins to move to the back.

In my post "Project Management through Lists", I spoke about maintaining a strategic view of the program/project and this is where leading from the back begins to come into play. For the use/test cases, it is important to ensure all business processes are identified which is more difficult to do when technicians are looking at all the detailed paths. The same concept applies when looking at a balance between different business requirements. A follow-on project may be defined to decrease the time to market for a software application serving customer service representatives. Time to market is the parameter the project is intended to improve but if the solution also decreases performance, scalability, and maintainability, will it be accepted or deemed appropriate over the long term. Probably not, so leading from the back and keeping a strategic view of the solution is also an important activity.

The side effects of leading from the back enable us to look at the pace of multiple parameters important to the concepts of project success and staying on schedule including:

• burn rate of budget
• pace of development across the multiple parallel threads such as interfaces, conversions, code development
• pace of knowledge transfer to operating organization
• mix of staff across labor categories
• assignment of staff across technical activities and potentially moving resources.  This is where "Utility infielders on Projects" comes into play.
• mechanisms to achieve business requirements

There are times when leading from the front is needed such as when engaging with the business or when activities are not going well. For the most part, leading from the back seems the most appropriate place as it also frees the technicians to be creative and implement their ideas on the solution which ultimately makes them happier and more productive. Clearly, the Program Manager who is leading multiple teams and will spend a majority of their time with the business is going to lead almost exclusively from the back. Ultimately, this is the best place from which to understand and manage the fundamental measures of project success.

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.

 

Project Management through lists.

Can a project manager be successful by focusing on and managing through lists?  

The answer to this question has a couple of aspects depending on the purpose of the list.  

Many implementation methodologies contain checklists for the purposes of project planning, project monitoring, technical or functional reviews or test phase preparation as examples.  These lists serve a valuable purpose of reminding the technician or project manager to consider an exhaustive list of concepts or ideas when executing a specific task common in many projects.  These items for consideration were typically born from best practices and lessons learned over many previous projects. These lists of reminders are valuable as they remind the individual of details that may othewise be overlooked and should have a place within any project.

Many project managers also use action item lists or lists of issues to which I referred in Issue Lists: Are they a good thing? and I defined some of the pitfalls with using lists for technical issues.  Clearly, driving issues to closure is part of what a good project manager includes in their day to day activities but this is only a part of the overall tasking.

PMs who focus exclusively or even mostly on working lists of issues do not always place enough emphasis of  what I would consider even more important elements to managing the project.  These include but are not limited to:

• Physical and mental state of the project team members
• Confidence of the stakeholders in the project progress and documentation thereof
• Stability of the functional and technical baselines
• Risks and progress on the risk mitigation strategies
• Financial baseline and performance
• Adherence to defined development approaches such as configuration or release management
• Education/training of the individuals who will maintain the system and their progress
• Change control and the inherent business decisions

Having a list of actions can be a valuable part of what a PM does each and every day.  When this action item list becomes the focal point of the day, the PM begins to loose the larger picture on the project and their capability to manage the project.  If a PM has the luxury of an assistant, the action item list is better suited for that individual.  As with most of my projects, this task falls to me but I spend a vast majority of my day focusing on elements such as defined in the list above.  This ensures I keep a good overall grasp on not only the technical aspects of the project but also the non-technical such as financials, human resources, change control, controling, and monitoring.

Issues Lists: Are they a good thing?

In many implementation and development methodologies, the concept of an issue list is prevalent and in many cases considered a critical component of managing a project.  This list is used to identify and track progress to closure of many different "issues" on the project including decisions by the business, detailed design or requirements questions, managment issues, etc.  The format and content of the lists vary as does the content of the lists.  Are these lists a critical component of managing a successful project or are they are common misconception that leads to unstable technical baselines and the downside of scope creep? 

This post will examine this question.  First, let's define some terms for the purpose of discussion.

Issue list - a set of questions, concerns, decision points that require resolution and specifically do not include issues found during the testing cycles which are commonly referred to as defects, bugs, trouble report, software trouble reports, etc.

Technical baseline -  a set of documents that uniquely describe both the requirements including business, technical, functional, and non-functional as well as the detailed technical designs on how to either develop software or enter meta data into a previously built commercial software package.

With these defintions in mind, the question remains are issue lists a good thing?  

One of critical aspects of managing a project is to understand the requirements, devise a strategy and plan for building the solution, then defining the solution to be built.  In the agile methologies, the order may be different but in all cases there is a starting point for developing software or implementing a commercial package.  When this starting point changes, the solution may change which we all know tends to extend the schedule even when we plan for that change as with agile.  This technical baseline becomes the guide.

A second critical aspect of managing a project is defining and maintaining this technical baseline.  When we create multiple documents which define the baseline, we create a situation whereby many documents have to remain in synchronization.  The difficulty of this situation increases expontentially as the number of documents in the technical baseline increase.  In a typical waterfall project, we have a requirements document and a small number of detailed design documents for solution components like interfaces, custom software, maybe some user exits, etc.

What happens when we write let's say a interface design.  Parties get together to review said document and identify a set of issues which we might maintain in an issues list.  Perfect, right.... Well maybe not...  The next logical step is to work the issues including status updates and proposed resolutions.  Eventually, we get the resolutions completed and documented in the issues list.

Now we have to go back into the detailed design document and integrate the issue resolutions into the design.  This seems unwieldy and redundant...  If we don't go back and integrate the issues resolutions with the design, we end up with a detailed design which has some of the design and a series of issue which have other parts of the design.  Even in an agile approach as the customer comments begin to mount, who and how does the project manager ensure all the issue resolutions are consistent and included in the solution.  How does it all fit together then becomes a problem.  In many cases during an agile project, the solution is the consolidated set of resolutions and a single location in which to look for the latest baseline.

Worst still is someone who is not familiar with the design has to read the design and all the issues which may apply then determine how they think the issues and design fit together which may or may not be the same interpretation as every one else.  These leads to confusion and an undermining of the technical baseline.

So what is a better way to handle?  In my experience, if something is important enough to make an issue, it should be recorded in some document that is part of the technical baseline.  This could be a requirements document, interface design, software design, etc.  When issues are defined, they are in context to some language in one of the technical baseline documents or is new language that should be in such a document.

Given this is true, how about maintaining the issues within the documents.  Most modern word processing or spreadsheet applications have a comment feature so issues can be documented in the actual documents. If an issues arises with Section x.y of the document, the individual identifying the issue enters a comment at the sentence(s) where the issue arises.  The side benefit is there is no need to define pointers into the source document or confusion around what langugage is being questioned as exists with an issue list as the pointer to the document and page must be included in the list.  This can be cumbersome and confusing in its own righ.  These issues are then worked in context to the overall design and language is integrated into a single document.

One downside to this approach.  Many project managers like to have a consolidated set of issues they can work and this solution makes that difficult.  I would suggest the upside to maintaining a stronger technical baseline far outweighs the extra effort required to manage through the technical baseline.  In a future post, I will discuss the concept of managing by lists.

The last point is there are a set of management activities commonly included on an issue list that should remain in a separate and consolidated list.  These issues include management activities not directly related to the solution.  Issues such as lack of VPN access, or developer needs a physical access badge for the building, visas needs to be approved, individual staff needs counseling, etc.  These issues are appropriate and I typically track as part of a periodic status report.

Does a good technical solution define a successful project?

As any project nears the end, the project manager can ask themselves this question.  The solution has passed all the defined tests, documentation is in place, and the customer is ready to go live.  Has the project been a success?  This leads to a different question which is what constitutes success?

In the scenario defined above, the technology will function according to spec but can the receiving organization operate and maintain the solution.  Can the staff run the interfaces, troubleshoot issues as they arise, make adjustments to either configuration in a commercial software package or custom code as the business needs evolve.  This assumes of course the project team does not remain on to perform these functions but is an important question to ask.  In my experience, project managers should be equally interested in this second aspect.

In an earlier post, I wrote about Education Strategies and this is where they fit in.  During the course of the project, project managers should execute on the Education Strategy to ensure that all parties who will ultimately operate and maintain the solution are both gaining those skills and knowledge but also gaining confidence in those skills and knowledge.  As part of that execution, monitoring the progress of each user role and individuals within that role is important.

At times, this requires a balance between being "helpful" and providing answers to questions, providing tools, etc and allowing the individuals time to immerse in the new solution.  This immersion and gaining first hand experience are keys to gaining confidence.  For example, I remember the first time I opened a spreadsheet application and looked at the grid.  My first question was ok, now what?  I had no idea where to start.  After working through some simple examples, I started to get the idea and both my knowledge and confidence grew.  The same is true for anything new.  This can be a difficult and anxious time for staff but is far less anxious when accomplished in a test environment than in the first few weeks of a production environment.  Many times, I get the question "why won't you just tell me" or "why don't you just provide me the SQL?"  This stems from pushing the staff to get immersed and build their own confidence and at times, the project manager in hot water.

This approach positions the receiving organization not only with a good technical solution but a staff that is both knowledgable and confident in their abilities.  At this point, I believe the project has been a success.

Test Management Philosophy

In my previous post, the discussion centered around a minimum set of metrics needed to effectively manage a testing program whether that program is an integration, system, or user acceptance test and exclusive of the development model used.  In nearly all cases, a project will have a more formal test phase in which a set of pre-defined tests are executed with the outcome being a move to production.  Given the assumption of utilizing the minumum metrics set defined in Testing Metrics, several management principles come to mind to move through the tests in a quick and efficient fashion.

The managment principles that have assisted me are:

• Focus on completing the maximum number of test cases between builds

At the outset of any test program, the complete set of test cases must be run and no bugs exist.  At the point that bugs are issued and fixed, the questions become when to rebuild the test environment and the extent of the regression tests.  My preference is to execute as many test cases as possible before rebuilding the environment and ideally execute the entire set until all test cases are either passed or blocked by a bug.  What the PM achieves is to identify the maximum number of issues and identify the most stable and least stable components of the solution.  By maintaining a substantial queue of issues, the development community can maintain a steady effort without any wait time as this community will typically be the driver for schedule.

In most test programs, this will take several days and assuming the development community begins bug fixing immediately a set of bugs will be ready for a build.  At the point where all test cases are either passed or blocked, the test program is ready for another build thus freeing up additional test cases for execution.  This principle makes a steady work queue for both the testing and development communities and affords the highest likelihood of the quickest progress towards completing the test phase.

• Focus on the completion of tests and not fixing bugs.

Once periodic builds commence, the test program is in an iterative cycle where all the tests are run and the developers work to unblock the maximum number of test cases with each build.  The testers are faced with a question of whether to regression test bugs or focus on the newly unblocked test cases.

With each build, I focus on the new unblocked test cases to get through all test case steps in the quickest possible time.  What this achieves is to uncover as many bugs as possible and ideally getting to the full set of bugs as early as possible.  Once the complete set of bugs is known, the PM has additional techniques to determine the ultimate questions of:  Am I on schedule? and When will I be done?

Regression testing of the bugs will need to occur but is a secondary concern early in the test program and can occur after all test cases have run through all their steps.  If the testers focus on bug fixing and not test case completion, it drives the test program into a state of constant regression testing where builds are requested frequently, the progress through the test cases both slows and becomes unpredictable, and the early test steps are executed many more times than needed as they are executed with each build.  All of these ideas result in a slower and less predictable test program.

• Define bug severity or priority levels and stick to them

One of the cornerstones of any test program is the categorization of identified bugs and the communication to the development community as to how big a deal each bug is.  Bugs are either categorized using a severity measure which speaks to the impact on the requirements associated with each bug or priority which speaks to the order in which bugs should be fixed.  At the end of the day, I beleive either is a viable manner to identify the urgency of the fixes but the main theme is to publish the definitions well before the outset of a test program and stick with those defintions.

The tendency of many organizations is to define the levels but get more "flexible" with the definitions in the heat of the testing program.  Individuals have their own points of focus and can stray from the definitions as their preferred functionality identifies issues.  Maintaining the definitions enables the development community to focus on the issues that have the greatest impact on the overall requirements and as stated above enables the test program to move through all the test cases in the quickest fashion.

• Structure the tests around business functions

The structure of the test cases plays a big role in the reporting of progress through the test program.  When speaking to the project sponsors, the conversations are more fruitful when speaking in the terms of the business functions.  If the test program centers on taking sales orders, then a structure around web orders, store orders, returns, exchanges, etc makes sense to the sponsors vice a structure around a set of interfaces or technical solution components.  By structuring in this fashion, the PM can report for instance that web orders are working except a detailed scenario such as multi-line orders when a single line has more than one delivery date.

This structure also typically dovetails nicely with functional individuals within the organizations and enables the PM to focus developers with an individual tester to more quickly understand the issues and confirm fixes.

• Manage using the metrics

The metrics defined in my previous post provide the PM a framework for priortization.  When executing the maximum number of tests, the PM quickly finds a situation where all the issues cannot be fixed in each build and typically more of each severity/priority level that can be fixed.  The question becomes where to begin.  The bugs blocking test cases metric provides a quantitative measure of which bugs block the greatest number of test cases.  By working issues first that are blocking the maximum number of test cases, the PM can unblock the maximum number with each bug fix and keep moving through the test cases in the quickest possible fashion.

In this model, there may be instances where a priority level 2 bug is fixed before a priority level 1.  This may seem counter productive but is in sync with the notion of moving through the test cases in the quickest possible fashion and identifying all the bugs as quickly as possible.

By using these principles to define priorities during any testing phase, movement through the testing phase has become quicker, easier, and more predictable.  All of these elements are important to the PM as validating proper operation of the solution in a predictable and quantitative fashion is a key element late in the project and a cornerstone to get a decision to move to production.

Test Phase Management - Simple metrics for effective management.

As we all execute testing programs whether it is a integration, system or user acceptance testing phase, the two questions that consistently arise are:

• Is the testing phase on schedule?
• When are we going to complete the testing phase?

For many people, the questions are answered with statments such as:

• The test cases will be executed by the end of the week
• If the developers can solve all the bugs by a certain date, I will complete executing the tests by a certain date

In a nutshell, the responses tend to be relative to some other event while the people asking the question are looking for an absolute answer.  How do we quantify the response in terms we can defend?  I use a set of two metrics and trends over time for each that address the fundamental questions.  These metrics are test case pass percentage (testing progress) and trend over time and open bug count and trend over time.  These two metrics provide a quantitative measure and a backup measure so the project manager has two data points that point to the same timeframe.  These metrics assume test phase exit criteria of all test cases pass and all severity bugs are closed which I find typical.

Let's start with the Test Progress Metric which documents the percentage of all test cases defined and passed for the testing phase.  The numerator is the number of test cases passed and the denominator is the total number of test cases in the test plan.  Over time, the number passed is recorded on a daily basis and percentage plotted over time.  This trend line is then projected ahead to 100% for the completion date of the test phase.  The trend of test case passing follows a linear pattern for most of the curve so any linear projection method affords a good view of the completion date.

The main advantage to this metric is it combines all the major elements that impact test phase completion but are either unknown or not easily measurable.  These include:

• At any point in the testing phase, the number of additional bugs that will be found.
• The rate at which developers will close bugs
• The rate at which testers can regression test repaired bugs

I have seen many organizations attempt to measure these parameters or define quantatively these unknowns but with little success.  It is more cost effective to use the defined metrics which naturally address all these questions.

Stability in the total number of test cases is critical here as instability in the denominator creates an unstable trend line so any risks associated with test plan instabiity need to be mitigated up front.  If the instability occurs, the best approach is to recalculate the daily completion percentages, replot the curve, and the projections.

The second metric is open bugs and the trend line.  Similar to the testing progress metric, the number of open bugs is recorded on a daily basis and plotted over time.  Unlke the testing progress which uses a percentage, the open bugs is an absolute number.  The severity level of the bugs needing closure for the test phase to end should be the set used in the plot.  In a typical project, this is the severity level 1 and 2 bugs but it could differ depending on the individual organization and the bug management process established.

The open bug curve will follow a hypergeometric distribution which has a big hump early and a long linear tail as it approaches zero.  This linear section is where the PM can also use any linear projection method to determine when the bug count will go to zero.  Given the upward portion of the curve early on, this curve is only helpful after 60%-70% of test cases are pass.  It will typically fall very close to the testing progress curve and provide a backup to the date projection derived from testing progress.

I have found these metrics to be very helpful in answering the questions from sponsors and are easy to defend.  If anyone would like to see examples of these trends, feel free to contact me either on the blog or twitter @mdgibson.  In a future post, I will walk through some test phase management techniques and how they compliment the testing metrics.

Travel Models and their effectiveness

For any of us that have spent any time as a Road Warrior, we know that travel is both a curse and a blessing. We get on a plane at the beginning of the week and another at the end.  Over time, we get to know the flight attendants, ticketing agents, customs agents; and the fellow Road Warriors who take the same planes.  Connections through the SouthEast during the summer can be delayed by thunderstorms.  Travel in the NorthEast in the winter and the snow can tax the patience of any seasoned Road Warrior.  What we save is the daily long commute typical of many cities.  So what travel model should a PM initiate on a project. There is no right or wrong model to follow so I will articulate the models I have used and what in my humble opinion are the pros and cons of each.

M-F full 8 hour days, travel on Fri PM and Sun PM

This model is extremely taxing on anyone and using it for limited periods of time such as during high intensity testing periods or around production dates can be beneficial to a project.  Attempting to use this model over the life of a project tends to wear out the travelers as they are away from home during the week, need to conduct any personal business on Saturday, then prepare to travel again on Sunday.  There is little to no downtime and it is very restrictive on the personal lives of the travelers.  

I have used this for 2-3 week periods at the maximum and try to avoid this model all together.  Travelers will typically get worn out, have issues at home and in the end either get sick or lose productivity or both.  Neither of those situations benefits the project.

M-Th, travel Th PM and Mon AM, 40+ hour week but off on Fri

This model is sustainable over the long term and has been effective for multiple months at a time. The main advantage is using Friday as the personal day for conduct of personal business which we all need to do.  Activities for home owners like cutting the grass, trimming the hedges or taking the kids to school are all activities not achievable away from home but enhance a travelers personal life and thus make them more effective while traveling.  This leaves Saturday as a full day off which is needed but most people.

A small tangent here to philsophise.  With my travelers, striking a balance between their personal life and work enables the travelers to be more effective.  For each individual, a personal life is important and means something different.  Even on the road, working all day and all evening is not sustainable as several travelers of mine have become severely ill from overwork.  Assisting the travelers in striking a good balance between their professional and personal lives is a critical component to keeping workers effective and delivering the project.

M-Th, travel Th PM and Mon AM, 40+ hour week, work on Fri

This is the model that I typically find myself in as I am a workaholic.  Case in point, I am writing on a Friday morning... If the project manager can minimize the number of meetings and other demands on the travelers time, this model can be sustainable as the travelers can spend some time during the day to conduct personal business.  The Saturday is left as a downtime day for soccer moms and dads or days at the beach, etc for the single crowd.

Not on-site each week, but with other model for on-site times.

This is the model which I like the best of all.  In today's times of telecommuting and remote access, IT projects especially can operate effectively off-site for long periods of time.  There are high touch times during a project such as requirements gathering, testing periods, or production days were being on-site is critical, but also other days of heads down development or other independent work where being isolated enables many travelers to focus and actually be more productive.

There has to be a balance here and a higher degress of productivity monitoring in these instances.  Typically, I provide daily or weekly milestones for the off-site workers that align with the project plan to ensure the project stays on track.  The typical concern is workers will not work which is valid so getting very measurable will mitigate this risk.  When the workers do travel, they are more receptive to longer or higher intensity periods.

In all cases above or with any model, the project manager is tasked with delivering the project and this requires other people to assist.  Maximizing worker productivity is a critical element to the success of the project and the travel model utilized is one component to maximizing worker productivity.  Striking a balance between the needs of people to have personal lives and the work demands of the project is a sometimes overlooked responsiblity of the project manager and in my opinion one of the critical success factors to project success.