Mark Gibson; PgMP, PMP

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.

Anxious Customer - Options on what to do - Part 2

In Part 1 of this post, several options for reducing customer anxiety were identified and explored.  In this final segment, two options are explored to reduce the anxiety of a customer and move forward with a project that is successful from the eyes of both the project manager and the customer.

In continuing the themes of providing value and collective intelligence, this post begins with the early stages of requirements gathering and development.

Get working software in front of the customer early and often

Nothing makes people more comfortable than to see something working.  This is especially true in the project management world today where some methodologies mandate large upfront documents to define requirements, architectures and the like.  These documents may serve purposes but do little to alleviate the trepidation inherent in large commercial software implementations or customer development efforts.

Where I prefer to start on commercial software implementations is to install the core product software in a development or playground environment as soon as possible and preferably the first week.  This enables the customer the first win of getting their development environment established and validating the software will run on their hardware.  If this is a Software as a Service (SaaS) implementation, the same concept applies although this is typically more about access than installation.

In those instances where the vendor has a reference or demonstration dataset used by the sales force, getting that environment running and/or granting the customer access enables the customer to see and work with the software.  We all know the horror stories about vaporware and sales demonstrations that were less than totally above board.  Getting the customer in front of the software initially and being completely open about its capabilities enables all parties to speak from first hand knowledge.  This environment is also well suited to the playground described in my post on Education Strategies.

Once this environment is established, it also serves as a prototyping or demonstration environment during subsequent project phases in implementation models using prototyping techniques or where document based requirements gathering sessions are used.  The greater the knowledge level of the customer on what the software can do, the more the anxiety will be reduced as it is the fear of the unknown that is most difficult to deal with and the greater the number of people available in the collective intelligence arena.  Even when gaps in a commercial product are identified, these are knowns that can be dealt with and the customer can make informed decisions vice a position of not knowing.

When possible, provide incremental updates on functionality that is either fully configured or fully built to support the production needs of the customer.  By demonstrating steady progress and providing the customer the avenue to both explore in depth and make adjustments to the eventual production system, the customer is able to gain confidence in not only the project team, but also the emerging solution.  It is very difficult for a commercial software customer to know how they will want a commercial package configured to meet their needs.  It is much easier for a vendor project team to build a working prototype, then demonstrate to the customer how functionality could work.  This enables the customer to work with the product, prototype options, and gain comfort the only question is how the system will meet their needs and not whether it will.  In these circumstances, the customer is in a better decision making position as they can see and work with the emerging solution before making a final decision on configuration.

The risks the project manager faces are in terms of cost and schedule.  Controlling the pace of working through the functionality and getting final decisions from the customer on configuration are key to delivering on time and within budget.  I have found that timeboxing the prototyping efforts similar to the iterative approach timeboxing works well.  This affords the project team and customer experts a set period of weeks to work out how any subset of functionality should work.  The PM should also allow time at the end when all subsets are in the environment to ensure proper and effective operation of all subsets in a consolidated fashion. 

In custom development projects, the same concept applies but in this instance, the custom screens are delivered incrementally.  With each subsequent delivery, the customer becomes more familiar with the emerging solution.  PMs should allow time in each subset to incorporate the feedback.  A critical idea is to ensure the feedback is incorporated in a rapid and predictable timetable.  A great deal of trust is lost when feedback is received and not incorporated.  Rapid feedback incorporation builds the trust and knowledge the project team is interested in building the best solution and the customer has good ideas about how to ensure that.  Regression time and risks are reduced when the release plan starts at the beginning of the business process and works through all use cases until the end.  For example, login is always the initial subset built as end users log in first.  With the delivery of additional subsets, the starting point for testing is always logging in so the regression testing is naturally conducted.  The same applies for all the main use cases.  I will address release planning in a future post.

Communicate early and often

Open communication and transparency are two key tenants in my post and of the Enterprise 2.0 approaches and they are critical to building customer confidence and therefore reducing anxiety.  This begins with the initial meeting of project manager and customer team and continues throughout the entire project.  It is better to over communicate than under communicate.  At the outset of the project, the PM will quickly get a feel for the frequency and depth of communication desired by all customer project team members and executives.

Initial meetings should always be in person so each party can see the face of the person with whom they will make the journey.  Face to face communication is typically more effective as it is perceived to be more personal and people are easier to trust when they have met face to face.  The PM should strive to have status meetings face to face and whenever bad news is to be delivered.

Early in the project, basic strategies are being formulated and negotiated and define the initial opportunities to establish the relationship. Having these face to face also builds trust and repoire.  More importantly, is for the PM to define and elaborate on all the  basis behind the methodologies being recommended and all the strategies developed.  Past experiences and how they either do or could relate to this unique situation enhance the transparency of the PM and rationale behind the current set of decisions and all future decisions.  Transparency is all areas should be immediate, never wavering, and absolute.

This transparency is most difficult when issues arise especially issues with a vendor product, but is also the more important time to be transparent.  Concealing a problem is a difficult thing for a customer to overcome if the PM is not the one identifying the issue.  In my experience, it is better to go to an executive with a problem and that the PM is working on the solution than to have the executive find out about the issue before the PM is able to brief them.  Ideally, presenting a solution with the corresponding solution or set of solutions is best but not always possible.  

When presenting issues and solutions, additional trust and confidence is built when multiple options are presented for the solution.  This demonstrates several ideas including the PM is thinking through the solutions, has interest in the feedback of the customer, and is creative in their thinking to recognize multiple options for a solution.

In summary, customers are anxious for many different reasons and rightfully so.  Relieving and overcoming this anxiety is critical to building a successful relationship and managing a project that is successful from the eyes of all parties.  In this post, we discussed getting functionality in front of the customer early and often and to communicate early and often as ways to build trust, demonstrate value and progress, and reduce anxiety.

Other recent posts include:

Education Strategies for Enterprise Software Implementations - Part 2

PodCast: Interview on Resuscitating a Red Project Team

Anxious Customer: Options on what to do Part 1

Resuscitation of a Red Project Team

Have Multiple Releases: A Different Approach to Maintaining the Branches

Education Strategies for Enterprise Software Implementations - Part 2

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

Formal Demonstration

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

Prototyping

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

Testing

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

Playground

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

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

Other recent posts include:

PodCast: Interview on Resuscitating a Red Project Team

Anxious Customer: Options on what to do Part 1

Resuscitation of a Red Project Team

Have Multiple Releases: A Different Approach to Maintaining the Branches

Leadership Question: Does the PM work for the resources?

Podcast: Interview on Resuscitating a Red Project Team

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

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

Anxious Customer: Options on what to do! - Part 1

We have all begun projects where the customer is anxious.  The larger or more complex the project, the greater the anxiety tends to be.  Customers can be anxious about projects for many reasons including:

• redesign of key business processes and unsure if they will work
• can be career makers or breakers (especially for mid to upper management)
• large monetary amounts involved so greater scrutiny from internal sources (audit, finance, board, etc)
• unsure if business customers will accept the new solution
• executives may be unsure staff is capable of executing on a large project

So how do we fix the situation as the risks mount the longer the project proceeds without dealing with the reasons for the anxiety.  I think there are three main focuses to reducing the anxiety within a customer for commercial software implementations and two for custom development projects.  I plan to address the first area in this post and the other two in a subsequent post.

The first step applies to commercial software and is to educate the customer on the software to be implemented.  This education should include vendor available product training focused on the options for configuring the product.  Focusing on the configuration options vice end user screens enables the customer to see the flexibility the product encompasses thus building their confidence the product can be configured appropriately for their unique environment.  Trainers should focus on these options and resist the temptation to determine what is "best" for the customer.  Ideally, this training should occur during the initial weeks of the implementation to provide a solid foundation in the product for subsequent requirements gathering or prototyping activities whichever approach is chosen.

While the customer is off at training, the implementation team can install the software in a development environment.  This does require the pre-planning to ensure the hardware is available at this early stage and can typically be requested as a pre-requisite to the implementation team coming on-site.  If the vendor has a demo instance or reference implementation that was used during the sales cycle, this will work best as it answers the question "Will the software work at my site." This enables the implementation team to meet the customer with the first task completed, demonstrate value, and demonstrate the sales presentations are reproducible in the customer environment.  These two items have enormous value in making the customer less anxious.

The implementation team can also quickly schedule demonstrations of the functionality in more depth than demonstrated in the sales cycle.  In this case, allow the customer to steer the conversation to those areas where either concern was identified during the sales cycle or where functionality was not completely understood.  The presenter who is usually the senior technician can also use this opportunity to demonstrate the flexibility of the product and the technician's expertise.  Gaining confidence in the senior technician helps to overcome the second typical concern which is can the implementation team execute a successful project.  This is also the opportunity for the project manager to take center stage and also applies to custom development.

At some point during these demos or the first few days of the implementation, I typically like to brief the implementation methodology in its raw form including the template project plan.  Since the briefing is typically to the executive level, the first couple levels of the work breakdown structure are deep enough.  Highlight the threads such as training, design, testing, all areas where the implementation team will interact with the customer, and how the solution comes together during the later project phases.  This will ease anxiety by demonstrating the project manager has done this before, the implementation/development team will work with and collaborate with the customer to ensure the best solution, and the project manager is focused on ensuring the customer can operate and maintain the solution once live.

After initial demonstrations in the sandbox environment, deliver the product documentation to the customer and encourage them to read through it and walk through the various configurable options in a sand box environment.  As with any new material, reviewing the documentation with an environment available to work in will increase the knowledge retained during the activities and reinforce what was demonstrated.  As the customers gain confidence with the software through trying the different options, their confidence in the emerging solution will grow and their anxiety reduced.  The side benefit is the customer can be more collaborative during the project since they are more knowledgeable so the collective intelligence of the project team is greater and that will reap benefits throughout the project.

The second post will focus on development models and which work best as well communication.  Stay tuned.

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.

Education Strategies for Commercial Software Implementations - Part 1

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

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

1. Formal Classroom Training

• Use Vendor training first

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

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

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

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

Part 2 of the series is now available.