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

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.

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.

Project Planning Techniques: Approach for getting to a project schedule

In most projects, a project plan including a work breakdown structure (WBS), resources, dependencies, and durations is a very early deliverable for the project manager.  From the charter, if available, the project manager defines a project plan with a major objective to get to the go-live date for the project.  There is great pressure very early on to get to both the go-live date and the cost.  In order to properly get to this plan and schedule, what are the activities required and the appropriate order to ensure the most solid project plan?  The paragraphs below define recommendations for those steps and the order.  There may be some variance depending on the organization, contract structure if applicable, and the implementation methodology.

Program Management Plan

One of the key deliverables in the initial week or so of a new project is the Program Management Plan (PMP) discussed in more detail in the this post.  This deliverable defines multiple key underlying processes that do not manifest themselves in tasks on a project plan but provide a process foundation upon which the project plan is built.  Key processes and management plans defined include:

• Communications Plan
• Risk Management Plan
• Configuration Control Plan
• Education Strategy and Plan
• Test Management Plan
• Quality Assurance Plan

Once these underlying processes are defined, detailed tasks and assumptions within the project plan unfold.  For example, if the Quality Assurance Plan calls for a detailed design review or a code review the project plan will naturally include these tasks.  The configuration control plan may include the process constraint of building all new environment directly from source control vice another environment which enables the project manager to ensure all solution components are both known and under source control. The Education Plan may contain formal training sessions for end users that spawn training material development and training conduct tasks.

Risk Assessment

A formal risk assessment at the project outset can be included as part of the Risk Management Plan in the PMP.  This assessment affords the project manager and any project sponsors to take a comprehensive, thorough, and global view of the project to ascertain assumptions, processes, staffing, etc that may cause the project to go astray.  In many cases, companies and outside vendors like Deltek have formal risk assessment tools that provide the project manager a process for assessing risks and queues the project manager into areas not previously known to investigate.

These assessments will review the project and determine the appropriate implementation methodology, staffing profile, schedule, dependencies, etc and afford the PM the best opportunity to build a project plan with an appropriate balance between risk and the triple constraints of quality, schedule, and budget.  Given the potentially sensitive nature of the risk assessment contents, the list of risks is typically published to the entire project team while the supporting prose is kept to the project sponsors.

WBS structure first

The overall structure of the project is typically the first step within a project planning tool such as MicroSoft Project, Open Project, or Primavera.  Depending upon the implementation or development methodology, this could consist of the waterfall phases of requirements, design, build, test, and deploy or a more iterative/agile approach where scope is defined up front, the formal testing and deployment activities at the end, and the sprint structure is defined.  This also affords the PM the opportunity to look strategically at how the project will systematically move forward, the objectives of each phase, and potentially entrance/exit criteria for each major milestone.  Additionally, the PM can incorporate those PMP processes that include tasks such as quality assurance reviews or training.

This overall structure is also a good point in which to brief and reach agreement from the sponsors on the WBS.  Note at this point, we have not defined a schedule but are focusing on the management controls and project flow.

Scope definition

Assuming the project contains contracts or agreement pertaining to scope, the definition of this scope is the next logical step as it will inform the details of both the following detailed tasks and durations and dependencies sections.  The approach definition in the implementation methodology and WBS will define both how the scope will be defined and documented.  The testing and quality assurance plans and the associated tasks then define how the scope is confirmed satisfied by the solution.

Detailed tasks

Once the scope is appropriately defined, the people who will perform the work are engaged to define the detailed tasks required to complete the scope.  Consideration should be taken at this point to the order in which the functionality is built.  This consideration can have a profound impact on the testing approach and effectiveness so is a good point for the PM to provide input.

These tasks are defined within the project planning tool so the project plan becomes more than just a high level WBS and begins to take shape.

Durations and dependencies

The final step is to define the task durations and dependencies between the tasks.  There is a strong tendency at this point to begin to look at the schedule and adjust these two parameters to get into a pre-defined schedule.  I recommend PMs resist this urge in order to define an initially unconstrained schedule.

Schedule falls out.

Once all the above activities are completed, the PM has a well developed yet unconstrained schedule.  Unconstrained schedules are useful in they provide an initial view of the schedule.  In most cases, this view is modified to conform to business constraints or tasks and activities are reviewed to look for efficiencies that will pull the schedule back to the left and within achievable business parameters.  The market also have tools designed to review these schedules and provide insight into high risk errors and detect subtle errors that may drive out a schedule.

The approach at this point is to ensure strong reasons are available to change project or scheduling assumptions.  There is a tendency to take risks not normally permissible when an unconstrained schedule is defined and far outside of needed constraints.  PMs and project sponsors should reassess the project if finding themselves taking extraordinary risks to achieve the triple constraints.  What may make more sense is to return to the beginning of the project initiation or planning processes to understand and re-evaluate the basic assumptions of the project.

The post above provides a one approach for defining a project plan and associated schedule.  There are many nuances associated with the planning process that may define a process different from that noted above.  PMs can use the above process to fine tune their process if it is unique to their organization or use the above as a starting point.

Relationships between use cases and requirements

In some organizations, the terms use case and requirements are used interchangeably.  In some respects this is an understandable point as both are ways to define the basic functions that software must accommodate.  They are both typically defined early in the project, are used as a basis for estimating the effort involved in a project, are grouped so developers or implementation consultants have some structure during the development or implementation phase of the project, and they are also used as the basis for testing planning and completion.  In many ways, they are similar.  In terms of usefulness for test case and training material development, they are very different.

At the outset of any project, we project managers look to gain insight into what the solution must do.  In many cases, we ask our business users what they would like the new software solution to do for them and we call this list of items, requirements.  This approach is well seasoned and has manifested itself in techniques like Joint Application Design (JAD) sessions where groups of business get together and discuss their needs of the new solution.  Project team members furiously take notes as the items are identified.  Even though this is a well seasoned approach for developing requirements, it is difficult question for business users to answer because they do not think of their business in this manner.

In my experience, business people are well versed in how the business is conducted, what they do on a day to day basis and what information and in what format they need this information to be effective in their varied positions within any company.  This business context is a key differentiator between use cases and requirements.

When developing use cases, the project manager asks the business team what they do on a day to day basis, what they do on rare occasions, and finally what they do on a very intermittent basis.  These questions have the context of the business activities they perform.  In order to be complete, project managers can start with more senior executives or even the project sponsors to get an idea of the breadth of individuals from whom to solicit their day to day activities.  These are the use cases.  A similar interviewing process can occur with individuals but with much smaller groups so each group can focus on their area of responsibility.  The project team can collect the use cases from each team and consolidate them.

By collecting from each group, a natural organization occurs since each group is typically a functional group enabling the project manager to begin to organize the use cases and therefore the development or implementation activities into a structure well known to the people who will both be served by the new solution but who also are likely to determine when the solution is ready to deploy.

Besides functional business people, a prudent project manager will also interview technical staff who will both administer the solution, network, interfaces, and batch processing.  These technical use cases are equally as important as the functional ones.

When defining requirements, an interview is typically the well traveled path to definition.  Many services companies have defined templates or questionnaires to assist with getting a complete set of requirements.  All of these approaches prove difficult as each software solution is unique to the customer.  We typically find our requirements sets of incomplete and this realization does not occur until deep into the testing cycles or even as late as the first few days after going live.  As consultants, we are very conscientious about doing a good job but we are behind the eight ball.

A natural mechanism for developing use cases is to start with business process flows.  Business process re-engineering (BPR) was very popular in the late 90's as companies began to look critically at their internal operation.  On many occasions as part of an Enterprise Resource Planning (ERP) implementation, my project teams would start with the business processes, take the opportunity to identify areas of streamlining since the process data was consolidated and became easier to identify these areas.  Although BPR is less popular today, the definition of business processes can be a good starting point for use case definition as the use cases are each unique path through the business processes.

In previous posts, I have mentioned the advantages of process flow diagrams as they identify new paths that are not always apparent and provide a mechanism for being more systematic in the approach to define use cases.  My best projects have started with using process flows as the starting point for use case definition and then leveraging these use cases further down the line when writing test cases and even training material

Once the project manager has a good set of use cases including the happy and non happy paths through the business processes, these same paths become the basis for the test cases.  The difference with test cases is a test case should address each inflection point within the continuum of data that could pass through the use case.  For example, we may look at closing the AP books for the month.  The use cases will be the same but the test cases include open AP across the boundary as well as open and closed within the month.  This different data condition may lead to different handling within the solution.  Another example could be a calculation algorithm whereby negative numbers are not permitted such as in a financial example or were a zero is handled differently. All could be the same use case but different test cases so the unique data conditions are exercised.

Finally, the use cases can be the basis for the training material.  Given the use cases define all the business activities needed for a good solution, the end users will need to understand the keystrokes to perform each of these business activities within the solution.  At a high level, the trainers can take a representative set of test cases including the organization defined during the collection process and build training material off this set.  The unique activities are defined within a structure that makes sense to the business and is broken down into functional sets that align to the set of users to be trained.  What is remaining for the trainers is to capture screen shots where appropriate, define exercises and pre-stage data into a training environment if so inclined.

Although requirements and use cases are perceived by many organizations to be very similar or synonymous terms, the manner and context in which they are derived as well as the additional value of use cases in the testing and training realms define some separation between the two.

Planning for the unplanned

Planning for the unplanned sounds like a contradiction.  How can you plan for an unknown?  It seems like the definition of unplanned.  In some ways this is true in that project managers do not always known the difficulties we will face on a project.  Risk assessment and management goes a long way when we can be predictive about these potential unknowns or use our experience to identify potential future obstacles.  All of these techniques remain germane and prudent.

At the end of the day, there is nearly always some obstacle that arises on a project that comes out of left field on us. Maybe it is an unforeseen illness of a critical resource or proven technology that is incompatible with the current environment, or even an external obstacle like another project needing a planned human or technical resource.  I like to say there is going to be something we just do not yet know what it is.  So we are back to the original question of how to plan for that which is unplanned?

Cross train all staff to increase flexibility in task assignments

In a typical project team, each individual has their role and even individual staff may have specialities.  This single threading on technical or functional capabilities can work well especially early in the project where multiple tasks are available on which each individual resource can work.  Later in the project and especially during the formal testing periods, the project manager cannot pre-plan or anticipate where the issues will be and what the level of effort will be in any individual functional or technical area.  Given the unknown effort of an unknown number of issues in unknown areas, the project manager can best prepare for this situation by cross training the staff across functional and technical areas.  Ideally, each individual should be able to work in each area but this is not typically possible.  The best the project manager can hope for is to maximize the cross training possible.  With each area where multiple resources can work, the project manager is best positioned to react to the unplanned situation when it occurs.

Front load any tasks with float and prototype when possible

In our project plans, we will inevitably have tasks with float.  This float provides the project manager flexibility to determine the timing of when to accomplish these tasks.  When combined with the cross training above, front loading the tasks with float provides the project manager an option to add staff to critical path activities or start a critical path activity early and parallel it with its predecessor to some degree as a mechanism to decrease duration and recovery some schedule.  Early completion of float tasks frees the assigned resources to perform unplanned tasks.

Front load any highly technical or risky tasks

With any project, the project manager will identify those tasks with the most risk.  High risk tasks are one of the largest sources of unplanned tasks.  The high risk can come from uncertainty in the technical solution.  With this uncertainty comes the possibility of unplanned work when the original thoughts on design or implementation prove untenable.  By front loading these tasks earlier in the project, the project manager affords themselves a longer period of time to replan and recover.

Leave architect time for utility infielder tasks

In previous posts, I have described the concept of a project resource who can work across any functional or technical area and has the depth of knowledge to work on any task where it be a strategic task or a very tactical development or implementation task.  When possible, capacity with this type of resource also affords the project manager some flexibility when unplanned tasks do occur.  By having a resource with a wide skill set, the project manager can initially staff this resource on the unplanned task which provides stability to the efforts of other staff.  Maintaining stable resources on tasks until completion is well known to be effective in maintaining planned durations and higher quality output of planned tasks.

In a nutshell, planning for the unplanned is about producing a solid project plan with minimal risk then monitoring and controling task completion to maximize available capacity within the team.  By cross training, it provides the project manager greater flexibility when reacting to unplanned work.  Having the senior resource with extra capacity not only enables assistance to be provided to more junior staff but enables the project manager to assign a senior resource the unplanned task so to minimize any negative impacts that may result.

Is Documentation a critical component of the project?

With the initial development models like waterfall, documentation was a critical component of the project to both define and manage scope, gain agreement on design, and eventually determine if the solution met the requirements through the testing phases.  We as project managers used documentation as the vehicle to gain alignment with the community who needed the solution.  This trend has continued with the introduction of commercial software who provide a shell into which implementation teams enter meta data to tailor the commercial software to the unique needs of the customer.  Even today, with the introduction of web applications leverage Software as a Service (SaaS) or cloud-based offerings, documentation is a common component.

Documentation remains a good mechanism for recording how commercial software was implemented; the meta data entered to tailor the solution.  For the worst disaster recovery scenarios where the solution must be rebuilt, this documentation is the foundation upon which disaster recovery plans can be built.  Documentation of test cases and the test management controls associated with a firm set of test cases enable project managers to track testing progress and answer the two main questions: Are we on schedule? and when will we be complete?

As SaaS and cloud computing become more popular, these vendors maintain multiple backups of the environments and offer embedded disaster recovery not before seen with on-premise implementations. The worst disaster recovery scenarios noted above are not as relevant as before since the vendor is covering off on this conditions.  Furthermore, many of the vendors such as Salesforce and BigMachines offers integrated development environments (IDEs) with the cloud-based offerings so the documentation of designs and code can occur within the IDE and be backed up using the same mechanisms as the transactional data.  Even with on-premise implemenations, nightly backup can occur to simulate the same offering of the SaaS or cloud-based offerings.

Looking even further back into the development processes and considering the newer agile and prototyping methods of development, we can begin to question if detailed designs and even traditional requirements are a necessary and critical component of a project in today's world.  With these methods, the detailed design evolves as the users gain experience with the solution, exercise their business processes within that solution, and fine tune the design.  With the agile models, defining the contents of each sprint continues to make sense as this information is not typically captured otherwise and project teams can utilize the multitude of agile management tools like Version One to streamline the documentation efforts. At this point, some people may be claiming heresy as this discussion is questioning the well seasoned methods of scope definition and control.  To some degree I agree as eliminating all documentation does not make sense to me.  Can we critically look at the volume of documentation we perceive is needed and look to repurpose this capacity to delivering additional functionality to our customers?

For example, when two disparate groups are working on a common solution such as with an interface, then a interface design may make sense.  This can especially be true when working with two groups each with their own contract.  In order to confirm proper contract execution, the definition of the work through an interface design makes sense.  If we look at the same example and remove the contract constraint, the need for an interface design document may be different.

Even the documentation of code or an architecture could be questioned within this same context.  If we adopt the newer agile methodologies and do not have contractual constraints that drive the need for documents, do we really need documents on our projects?  Historically, these documents have been a mechanism to reach agreements but if we use close coordination such as what can be achieved with a scrum meeting or other frequent coordination forum, projects today can drastically reduce the need for documents and free up this capacity to build more functionality.

As we look at the risk profiles on our projects and build our project plans, we can and should consider when formal documentation is needed, when we can achieve tighter coordination through more frequent face to face (includes electronic through Webex or GoTo Meeting like products), and focus more energy on building more functionality for our customers.

Status Meetings: Necessary or a distraction?

Status meetings are a common occurrence on many projects. Project teams get together and project managers solicit the status of individual tasks from team members to update project plans or maybe understand the tasks individual resources are working on. These are certainly necessary activities but is a meeting the appropriate forum for soliciting this information.

Project team members and especially the more senior staff are typically strapped with a large volume of work and required to produce in a short period of time. Meetings in all forms take these especially as well as all team members away from focusing on their work. Some meetings are needed as these same members need to coordinate or make decisions with other team members or members of the customer staff. This problem is more acute when team members are heads down on difficult tasks or troubleshooting problems when uninterrupted focus is helpful to finding answers.

If not in a meeting, then how do project managers get the information needed to properly manage the project? In my projects, I ask the team members to carbon copy me on email traffic going back and forth between the project team and the customer. By monitoring this traffic, the project manager can understand the status without interrupting the resource's work or focus. When traveling, additional opportunities are available when eating meals. The project manager needs to know the staff as some individuals like a break during meals so sensitivity to the individual's needs must be acknowledged. There will be times when direct interaction on status is the only mechanism. By using these avenues to gain status, the project manager can minimize the amount of time spent getting status enabling the resources more time to focus on their work.

What should be the agenda of periodic meetings with the project team?

 In my meetings, I focus on three things: 1) the needs of the people on the team, 2) what I am working on to assist their efforts, 3) outside influences on the project whether those be within the customer or company in which we all work.  The needs of the people can be anything from technical issues on which they are working, access issues to for example a source control tool or test executive.  They can be personal needs such as personal time off or needs to coordinate with other team members or customers.  This aspect focuses on the team members and what they need to be successful and efficient.  If there are ways that I can help, then those actions are taken.

One of my primary focus areas is risk identification and management.  This is my opportunity to brief the team on my contributions as well as where their assistance is needed such as in project planning or the program management plan.  The risks I have identified are documented, understood by all parties and the progress briefed to the team.

Outside influences can hinder a project as we all know.  Understanding these influences and working to mitigate the effects is something project managers can spend more time doing.  These influences can be related to company policies, issues with housing arrangements for team members visiting from overseas, etc.  By spending time in these areas, the project manager can demonstrate they understand the day to day challenges, care about the lives of their people, and work towards making better work places.  What the project manager gets in return is a happier and most efficient work force which leads to higher levels of productivity and predictability.

Finally, I open the floor to any topic that any team member wishes to discuss so this is not my meeting but the team's meeting.  Typically, the topics are coordination between team members, when to work together on technical issues, more junior members asking for advise or discussing ideas on a task or issue.  I have faciliated discussions about hotel arrangements, personality issues between team members and customers.  A wide variety of topics are discussed and can be.

I know the question is coming so these meetings typically take less than 15 minutes when hosted twice a week.  On rare occassions they go longer but that is typically because the team members are having longer discussions on a topic.  Keep the meetings short!

In conclusion, status meetings for the collecting status are a distraction.  PMs should find other ways to collect status information so the team members can remain focused on the tasks at hand.  Keep the meetings short and focus on the needs of the team members.

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.