Home
About Us
Site Map
Products
Services
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Links
Contact Us
BLOG

 

 

Execute the Project Rescue Plan

“The basic process in this phase is governed by the activities described in the project rescue plan. The completeness of this plan should be driven by the following sources of information (which were used to construct the plan in the first place):

  • Original project plan  This should be a deliverable from the pre-rescue duration of the project.
  • Rescue methodology  This involves the four-phase methodology introduced in a previous segment and used throughout the Project Tips area.
  • Development methodology  This is a proven development methodology that describes architecture/design, development, and testing processes. It should be based on any one of a number of underlying philosophies, such as Agile Approaches, parallelization, or extreme development, that have enjoyed wide popularity in the Information Technology profession in recent years.
  • Best practices  Knowledge from industry sources for the type of project being followed can provide additional checkpoints for the project plan. For example, what are the key risks for an offshore development team using the same technology tools?
  • Practitioner experience  Every practitioner brings a great deal of experience with them that may not be captured in any other source. Solicit this information through walkthroughs and build their experience right into the plan.”

Architecture/Design Subphase

“The architecture/design subphase uses the business requirements to build a complete picture of the final solution. Here are some of the problems that could arise during this exercise:

  • Unproven solution  The concepts may have appeared to be fine in principle, but may prove to be unworkable. You may need to involve the vendor to validate a prototype, incorporate some manual processes, or work with the stakeholders to define a workable solution.
  • Too expensive  If the architecture/design is becoming more expensive than the budget that was allocated, consider scaling the solution back so that it can support the first year of operations and building an upgrade budget.
  • Setup  New architecture usually requires longer implementation time than generally assumed. The systems team almost always provides the most optimistic estimate. You should drill deeper to identify the areas of uncertainty. These should then be incorporated to adjust the estimate to a more likely range.
  • Different versions  You need to get the right software versions of the different tools installed and integrated. Simple version changes can have a significant ripple effect throughout an intricate architecture.
  • Bottlenecks  It’s difficult to get the right configurations of hardware components. Build several proof-of-concept or pilot deliverables that allow you to test various configurations.”

Development Subphase

“The development subphase is going to require intense sustained effort from the project team. Many activities will end up being done in parallel, as developers begin to deliver their components. These will enter the test cycles. Some components will require modifications to correct reported errors. Other components will be moved to the next subphase. New components will continue to be placed into the test cycles. Here are some of the specific problems to watch for:

  • Distance Development  Resources are becoming more geographically distributed, especially with offshore initiatives. It is a challenge to get the different groups to work efficiently together, especially to overcome the time-zone delays. All the groups must share some core hours, even if that means requiring some resources to be at work during their normal sleeping times.
  • Standards  This is another area that gets neglected during tight timeframes. Come into the execution phase with these already defined and use walkthroughs to help the team leverage them to their benefit. Standards will help make life easier for the team.
  • Changing requirements  Developers should be using the technical specifications or the documented business requirements to build the solution. New requirements may emerge, but these must go through the rescue manager and the change request procedure.”