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

Program Manager Role in License Sale

In course of selling commercial software, there will inevitably come a time when a potential sale begins to slowdown or even  stall.  This can occur for many reasons including:

1. Uncertainty of internal risks of large project
2. Uncertainty of load of project on internal staff
3. Uncertainty of how project tasks are inter-linked
4. Uncertainty if vendor is capable of successfully completing the project
5. Uncertainty if services staff understands the business and can model the business within the tool

For a IT executive, these items can slow or even prevent a software sale.  A Program Manager can help by briefing the executive staff on these items or any other concerns expressed by the prospect.  The software sales team can leverage the Program Manager in this capacity to close the sale as the Program Manager can build confidence within the prospect that is difficult for the sales team to achieve.

Given this opportunity in my past, the following item have helped me.

• Brief an implementation/development methodology including key decision points and risky aspects of the implementation

Whether the project is a commercial software implementation, custom development project or any combination thereof, the PM can begin with the overall approach to the project.  Start with a template or shell project plan and define the major phases including the major objectives and activities in each.  Keep the conversation at a high level and focus on the flow of the activities and their relationship to the project objectives.  The staffing needs, key decision points, and risks will naturally fall out of the discussion.

Identify the activities where deliverables are produced and where intense business involvement may be required.  The initial requirements gathering sessions are a typical example.  Describe how these activities have been conducted in the past, highlight and stress the interaction between the vendor staff and the technical and business staff of the prospect.  This reiterates the consultative nature of the activities and that the prospect will drive the end product.

• Focus on the non-technical aspects of the project including communication, training, testing, risk management, and change management

In my experience, many of the concerns come from the non-technical areas of the project and include: How will we manage change?  Will we come in on time and within budget? How will we ensure the prospect staff is trained and able to operate the solution once built?  How will the solution be tested?  How will data be converted from the legacy systems?

Walk the audience through the project plan template and highlight these areas in a separate discussion from above.  This will demonstrate the completeness of the template, sensitivity to the long term operation of the solution, and and also enable the audience to focus on individual areas of concerns outside the context of the technical aspects of the plan.

• Present multiple options for business related issues without committing

Always present multiple options for consideration as the options will be discussed and that decisions are made during the requirements and design phases of the project.  Attempting to make them in this timeframe is premature until all topics are thoroughly discussed.  Having multiple options to consider demonstrates an overall understanding of the industry and that the project may uncover additional business improvements not previously identified by the prospect.

• Present business examples directly related to the prospects business and how they were solved previously

In preparation for the meeting, work with the sales team to understand and identify multiple business examples from the prospect's current environment and that are relevant to the project scope.  The audience will relate much better to examples from their business rather than more general examples. If there are no known examples from their business, keep all the examples within their line of business as a retailer will likely have difficulty relating to a business example from a financial services company.

When presenting the business examples, focus on the solution to the problem and ideally the conditions under which the decision was made.  This helps the audience identify the problem solving and consultative skills of the Program Manager and how the teams will interact during the implementation.

• Explain the rationale behind any preferences

During the project plan template discussions, the Program Manager may have desired implementation options, techniques, or tools.  When identifying any constraints such as this, explain the rationale behind these preferences and how this preference has prevented issues in the past.  This level of transparency highlights the thought process behind the decisions and helps the audience understand how decisions will be made on the project.

• Questions from the executives typically highlight areas of concern

During the presentation, questions will inevitably be asked.  These questions tend to identify the areas where the audience is concerned and provide insight into the areas to focus the presentation.  The Program Manager should spend any time necessary to address these questions.  The main presentation is of secondary importance to addressing these questions.

Have a second services individual in the room with you as well to read body language.  This person can also help steer the conversation to address additional areas of concern, provide additional business examples, or additional options to consider.

In Summary, the Program Managers can be very helpful in closing business when the prospect has implementation concerns or questions.  By introducing to the prospect the individual who will be with them throughout the process, the sales team and PM can build the necessary confidence to close the sale.

Requirements Documentation- Let me Count the Ways

As I finish preparations to begin a new project, I have spent some time discussing several methods of documenting requirements.  More specifically in a requirements collection phase, at what point and with what audience do we put pen to paper with the deliverable being a requirements document.

The discussions in which I have been engaged in the last week have defined four basic scenarios that can occur, each with their own advantages and disadvantages and degrees of passion about the method.

     Conduct all meetings first and document later

In this method, the project team conducts the days or week worth of meetings, meeting minutes are kept and published.  After all meetings are conducted, a subset of the team begins the writing.  The writing is typically accomplished by a business analyst but any team member(s) can also accomplish. 

The advantages of this method are: 1) decreased time defining requirements so less business user time, 2) complete focus on requirements without need to discuss verbiage, 3) during writing, rest of team can accomplish other startup tasks. 

The disadvantages are: 1)  longer approval cycle as requirements wording is left to the end,    2) results of discussions may be lost.  This is a greater risk the longer the requirements meetings occur,  3) writers must spend time initially preparing and then reviewing meeting minutes to write final document.  Initial sets of meeting minutes are non-value add as they are duplicative to the final requirements document.

     Conduct meetings and document weekly

In this method, the meetings are conducted for a number of days during week which is typically either 3 or 4 days.  The remaining 1 to 2 days are used to document the results of the week.  A subset of the team is typically used for the actual document preparation and is well suited for a business analyst. Typically, the emerging document is reviewed weekly and prior to beginning the new week of material.

The advantages of this method are: 1) all parties can focus on requirements definition without overhead of documentation, 2) writers have dedicated time to document at the end of each week, 3) less delay between definition and documentation so time lapse issues are less

The disadvantages are: 1) some time lapse issues and verbiage issues remain, 2) time to define requirements is extended as time is spent dedicated to documentation, 3) time lapse issues created additional uncertainty on the approval cycle length and thus the associated schedule risks, 4) end user subgroups may be required to attend sessions split across disjointed weeks.

      Conduct meetings and document daily

With this method, the writers keep up with the daily definition of requirements and document said requirements during the evening hours.  This enables up to a 5 day workweek to document which may be useful when limited time is available either all together or with a particular end user group.  A business analyst remains well suited to the writing tasks but technicians with good functional skills can also accomplish easily. Typically, the prior day's language is reviewed prior to beginning the day with new material.

The advantages are: 1) lag time between definition and language agreement is substantially smaller eliminating the loss of agreement over the lag time, 2) the team is better able to monitor progress as the definition and language are agreed upon in a more incremental fashion, 3) individual subgroups of users are needed for a confined time as they are not required to come back at a later time to reach agreement on language.

The disadvantages are: 1) writers are required to put in additional hours at night and will loose effectiveness due to fatigue, 2) the days can be disjointed as language is reviewed at the beginning of each day causing greater stress on the end users, 3) the time lag of even a day can result in loss of agreement on the material from the previous day.

     Conduct meeting and build document in real time

In this final method, the requirements document is populated in real time as the requirements are defined.  All parties agree review the language on either a PC projector and/or via a web-based conferencing solution such as NetMeeting or Webex.  As individuals articulate the requirement, the writer types the new requirement into the final deliverable.  If the need for diagrams is identified, the writer can shift to a presentation graphics or business process flow application such as PowerPoint or Visio.  In some cases, PMs may decide to have a short document review after the sessions are complete, but great care should be taken to ensure topics are not reopened.

The advantages of this method are: 1) progress is incremental and easily tracked against the available schedule, 2) once all material is covered, the document is ready for signature and all parties have agreed on the language, 3) no time lag is created between requirement identification and documentation, 4) each end user subgroup is needed for only a single period of time vice coming back for a document review.

The disadvantages are: 1) writers have great pressure of them to either type in real time while interpreting the requirement or creating a diagram in real time, 2) end user may feel additional pressure since requirements are documented in real time vice having some number of days to review after documentation is complete.

In summary, I prefer the build as you go method as it provides a better gauge of progress, keeps all project team members focused on the goal of completing the deliverable, and typically has a smaller approval tail then the other methods.  The key assumption here is that parties are held accountable to the verbiage written as they go along and wholesale revisions are not made at the end.  This risk is further mitigated by publishing the draft on a daily basis.

How to stay on Schedule

At the outset of all our projects, we define work breakdown structures, resources, durations and eventually agree upon a project schedule.  As we wade into the project, we begin tracking progress against the schedule baseline and tick off the activities as they complete.  What happens when we begin to slide to the right and what techniques can we all use proactively to either minimize the chances of sliding to the right or ideally stay on schedule?  There are multiple techniques I have used in my projects to stay on schedule.

Front load the work

How many times have we all heard the cliche "Stuff happens?"  And in reality, how very true is the statement?  In my experience, there are always unplanned activities or setbacks on a project that both eat away at the available capacity and typically push the schedule to the right.  So how do we plan for the unexpected?

When both planning and controlling a project, I front load the work. For an activity that has float, I start at the earliest possible date given resources constraints.  This may be the early start date or earlier.  Keeping the resources utilized at 100% from the beginning is crucial to both building momentum on the project and getting ahead.  The tendency is to start slow and pick up speed later.  I take the opposite approach by starting early and keeping a steady strain throughout the project.

So when I plan the project, I take the hardest activities and schedule them early on assuming all dependencies are satisfied. This positions the project manager to best absorb those unplanned activities when they occur.  If the project manager is caught up short, then more time is available to catch up.

As an example, I would build out and install applications in a DEV environment while the up front planning and requirements are being gathered.  This activity could easily be pushed out as no development work has to occur very early  on.  What happens if the hardware is not available or there are issues with network connectivity or the software delivered is the wrong version.  These are examples of possible unplanned issues that could arise which can push the schedule to the right.  If we execute these activities early then if issues do arise, we have more time to address them.  There are exceptions such as training of end users before a deployment as an example.  Clearly, the timing of this is back loaded but training is an exception and not the rule.

To summarize, plan the difficult activities early and enstill a sense of urgency from the first day so time is not lost at the beginning of the project.

Pad and protect the critical path

As we all know, the critical path drives the schedule so protecting and closely monitoring critical path activities is a good idea on any project.  The idea of padding the schedule is not something new, but focusing this only on the critical path activities is worthy of note.  If the non-critical activities do not impact the schedule, then padding them only increases project cost so focus any padding on the critical path activities only.

Typically, I will add 25% to the durations defined by those estimating.  The amount appropriate is a number defined by the project manager after getting some experience with the team and especially the individual making the estimates.  The accuracy of any individual estimate is function of the individual.  There are some people that 25% is fine as their estimates are typically spot on.  Others might be 50% or even 100% off as they hone their skills in this area or more typically define the amount of time it would take them to perform the task.  There are cases where the estimators are highly skilled and efficient technicians and those that will perform the tasks are not as highly skilled so the estimates become systematically low.  The project manager needs to know their staff and make adjustments where appropriate.

Marathon and not a sprint

Projects are long term endeavors by definition.  They can range from a few months to years in length.  In the first suggestion on staying on schedule, I spoke about front loading the work which remains true. There is a tendency among people to try and finish everything in the first few weeks.  Over time, I have had individuals work nights and weekends very early in the project and wear themselves out.  In two extreme cases, the technicians made themselves physically ill from overwork and one even had double pneumonia. In these cases, significant work time was lost in the recovery.

From the outset in a project, I stress to the project team the project is a long term endeavor and we need to find a work and travel schedule, if applicable, that we can sustain for many months.  In our business, a 40 work week is something we all look and hope for but an 80 work week is not sustainable.  In the projects with off-shore components or with wide time zones differences, the early mornings and late nights can take a toll on resources.

The work schedules need to be worked out and only increased in few situations.  Even in those situations, the length of time to work deep into evenings and over weekends is limited to less than 5 consecutive work days and 2 weekends.  The tendency of project managers when getting behind in schedule is to increase work hours but this can have dire consequences such as resources getting sick, resigning, or decreased productivity due to fatigue.  If more time is needed to recover the schedule, the PM should consider formally moving the schedule to the right.

In one case, a project team in the middle of a testing cycle had an enormous number of open issues and my predecessor continued to ramp up working hours.  As the hours increased, the productivity dropped and the situation got worse.  One of the first things I did was to cut back on the hours worked and saw an increase in productivity.  Each team will determine the appropriate schedule so keep in mind the project is long and the team will need to sustain the schedule for the duration of the project.  The best way to avoid extra hours is to stay on schedule and using the techniques and concepts in this post will assist any PM in this difficult task.

Minimize churn

Churn is defined as a couple of different things.  One is reworking the same activity more than once. Clearly, we all plan to execute any activity only once so we need to stay with that as much as possible. This is where the concepts of baseline control come into play as both requirements and design changes in most development models cause rework and the subsequent sliding to the right of the schedule.  Even in agile models where some element of churn is planned for, the project manager must monitor this and the movement of the activity to completion to ensure schedule achievement.

Secondly, churn is the technicians getting stuck on a particularly nasty problem.  It could be connecting to other machines or processes or some complex logic that is not working properly.  In all cases, I set a standard for technicians of the amount of time they should remain stuck on a problem before getting another set of eyes or a support organization involved to assist.

Most technicians are highly professional and pride themselves on their capabilities to solve problems.  I treasure the spirit of these individuals but ask them to seek assistance.  This is also easier if a 2 person development model is accepted as the help is inherently present.  Obviously, if a technician is stuck on a problem, their estimates and actual time to complete an activity can be driven far out from planned which again impacts the overall schedule.  Getting them assistance once the nasty issue is identified is important for the project manager.

Deadline Accountability

Staying on schedule is not just the responsibility of the project manager.  The individuals doing the work also have responsibility for their individual tasks to ensure they are completed within the duration the technicians define.  This naturally implies the technicians are consulted on the duration and not pushed into agreeing to task durations that are not achievable.

I typically see this come into play when a top down schedule is defined and the project manager has to fit all the tasks into a pre-defined timeframe.  Many of these top down schedules are set by legitimate business needs and can be appropriate.  Where the project manager can stray is to get an estimate from a technician that is for example 2 weeks and the PM push the technician into a 1 week duration. Overly long durations are also not appropriate but a reasonable agreement by both parties on the duration is most successful.  Once the duration is agreed upon, holding the technician to this deadline is both appropriate and helpful to keeping the overall schedule on track.

Going back to the critical path padding, the PM really only needs to push on the critical path activities and not the ones with float.  It is also my experience when the PM gets front loads activities and minimizes the pressure on the technician, the activities many times come in ahead of schedule.  This cooperative and healthy working environment feeds mutual respect and success. It also gives the PM chips to play when a little extra effort is needed or the PM is in a bind and needs an extraordinary effort to stay on schedule.

This leads to a concept I call "Mini Crisis."  As intermediate deadlines approach, these deadlines need to be highlighted by the PM and made visible to the project team.  For example, if the development is to be completed by next Friday this should be visible to the project team at least a week ahead of time so all parties know of the deadline.  If the team is falling behind, this may be an appropriate time to call is some chips, ask for extra effort, or even weekend work.

By pushing for and meeting these intermediate milestones, the PM maintains a position whereby the normal work schedule is maintained, technicians remains productive and the schedule stays on track.  The tendency is to allow each to slip a day or two.  As the one and two day slips add up, the schedule begins to slip by a week or two at a time.  This precedent can overtake the culture on the project and lead to circumstances of a perception the schedule does not matter.  So when intermediate deadlines are in jeopardy, I will create a crisis to achieve the milestone.  By using the intermediate milestones, the crisis can be overcome in a much shorter timeframe enabling the team to get back on a normal work schedule.  The side effect of overcoming a crisis can be a closer project team that is better able to handle larger crises if they occur.

Minimize Distractions

In many situations, PMs will allow multiple types of distractions to enter an otherwise healthy project environment.  These distractions are more intrusive when a technician is executing a very complex or technical task and just needs to focus.  I call this "heads down" and is when a technician focuses exclusively on the task at hand and ignores everything else.  They may ignore email, phones calls, instant messages, etc.  Allowing technicians at times to go "heads down" is something the technicians will greatly appreciate and provide a better solution in less time.

Other distractions can be management that is currently unhappy or a customer that is nervous.  Most technicians "just want to do their work."  The PMs that can screen the distractions from the technicians will see better results faster.  These distractions can also be expense report approval timeliness, updating back office applications so email does not hit their inboxes, etc.  Anything that takes them away from "just doing their work" is important for the PM to focus attention on as it offers the best opportunity to meet individual milestones and therefore the overall schedule. 

Meetings are a constant source of frustration for technicians especially status meetings.  How many of us have sat through meetings where all parties talk about their individual work while someone updates a project plan?  Of course, updating the project plan is important from a monitoring standpoint but having everyone in a room for even one hour a week is a big drain on resources and capacity.

Other meeting such as reviews of requirements or design should only include those technicians who will have input into the decision.  Many PMs like to have everyone in the room during discussions so that everyone feels involved and has input.  This is rarely the case.  Most technicians can make their inputs to a senior technician then get the output in a five minute discussion.  The other 55 minutes is spent working on their tasks.

To get status, I ask the technicians carbon copy me on email pertaining to the deliverables.  In larger project teams, these tend to be distribution lists so adding me is a one time activity.  This enables me to both monitor progress and identify difficult or complex issues, but also get the status so I do not conduct status meetings.

The last distraction is admin like time sheets, expense reports, forms from finance or human resources.  It gets back to just doing their work.  These distractions eat up a great deal of time even though many are necessary. Find ways to minimize the admin workload.  When traveling, I used to buy lunch and dinner for the team every day.  This reduced the number of lines on the teams expense reports so less admin.  Having lunch together also allowed me to fill in any holes about project status or address concerns the team might have.  If forms needed to be filled out like for network access or physical access, I handled this.  Compiling lists, etc are all examples of administrative tasks that are necessary but if executed by the PM enable the technicians to focus on the work.

Time off

Everyone needs a break.  This includes evenings, weekends, and especially vacation/holidays. Sometimes it is difficult to find time to let people have blocks of time off but they need it.  Work out summer vacations early so the project impact can be minimized and project coverage can be maintained.  Protect their time off especially when they are meeting their deadlines.  My only exception is when they miss an intermediate milestone (the mini-crisis) from above.  Stellar performers will complete their work on time and with a sustainanble work pace will provide the backbone to a project team that meets their schedules.

Strong baseline control

Maintaining stability and control of the technical baselines is always a critical component to staying on schedule.  This topic has been addressed by many smarter people before me so I will refer each of you to those other works.

In conclusion, many of the topics discussed speak to non-technical aspects of the project and in particular managing the people.  Many PMs forget the people on the project team and their pivotal role in the success.  No PM has ever completed a project without their staff so providing a healthy work environment for the staff and keeping them productive is something that should remain in the forefront of the PM. Naturally, the technical aspects have to remain covered as well.  Using the techniques above will assist a PM in staying on schedule and out of the RED project scenarios.

 

An Approach for Scaling Agile to the Enterprise and Program Level

On rare occasions I come across an article that compells me to publish directly in this blog.  The November/December 2013 issue of CrossTalk published an article by Scott Ambers and Mike Line that met this standard.  Their article entitled "Disciplined Agile Delivery: The foundation for scaling Agile" is a description of how to scale agile to the enterprise and program level.  It is a unique approach for how we in the project management can overcome many of the challenges in implementing agile outside of either a production development organization or on a limited project basis.

http://www.crosstalkonline.org/storage/issue-archives/2013/201311/201311-Ambler.pdf

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.

Role of Use Cases on a Project

With the advent of more recent development and implementation models, the concept of use cases and user stories has arisen.  For the purposes of this post, we will use these terms synonymously.  Historically, the Information Technology (IT) community used requirements to document "What the system needed to do."  These functions were documented and cataloged then eventually tested at the end of the project.  Over time, we discovered that requirements were a difficult to define as end users typically do not think in terms of software functions but more in terms of what business functions they perform.  From this realization came the concept of user stories and use cases.  The concept has caught on making user stories a very common artifact on today's projects.  The questions then becomes how do we are Project Managers use user stories and are there benefits beyond what requirements afforded us?

Development or Implementation Requirements

The definition and control of scope continues as a focus area for PMs throughout the project lifecycle.  The early definition and continual control of user stories as the basis of development and implementation are central.  The creation of a backlog of user stories and the inclusion of software bugs in the backlog creates a different dynamic for PMs using a sprint based methodology but is similar enough to a requirements based model that organizations can make easy transitions.  Quality control mechanisms such as traceability matrices can continue to have a place in projects with user stories.

Basis for Test Planning

Where user stories begin to have additional value over requirements is in test planning.  In a typical requirements based approach, a team may have created testing scenarios from the requirements.  In many cases, this is an additional organizing step performed by the test team to organize the requirements into identifiable business functions to enhance and put context around test results reporting.  With user stories, this structure already exists natively.  Since the user community defined the business processes this organization naturally falls out and in terminology easily identified and understood. 

The inherent advantage both in test planning and reporting is this business context.  When a base user function like assign a lead in a sales operations scenario or put away an item in a warehousing scenario are defined, the users have a strong understanding of both what the function is and how is applies to their business and day to day operations.  When planning the tests, defining the individual test cases becomes easier and the business community can participate more fully and with more confidence.  The same applies in the reporting scenario where understanding which business functions are working becomes a critical input into the decisions to release new functionality to production.

Basis for Training Material Development

Working with the same theme, training material is best organized around basis business functions.  It can start with some high level like distribution, general ledger close, or even a little deeper like sales lead sourcing.  With the business context of user stories, this same organization is usable as an outline for end user or even administrator training.  Better leverage is gained when the UAT testers are trained using the training material before user acceptance testing (UAT) so the training material can be flushed out before the larger set is trained just before going live.  The organization of the training material and test cases are in sync giving the UAT testers an advanced step before training in addition to having attended the draft end user or administrator training class.

Basis for End User Guides

End user guides or quick reference guides are the final beneficiary of user stories.  These guides need to identify the key business functions and define the key strokes needed to accomplish.  The user stories identify the major and detailed business functions and the test cases define the key strokes leaving only reducing those two artifacts down to the material desired in a user or quick reference guide.

Given the user context in which user stories afford us, these stories have benefits the project manager can leverage during all phases of the project.  Whereas requirements require organizing and reorientation to an end user context that requires additional effort, the user stories already have this context so reduce administrative work.  It appears to me user stories have all the benefits of requirements but also enable efficiencies not attainable otherwise so PMs should consider user stories as their basis for scope definition and control whether the project is custom development, a commercial software implementation or a combination.

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.