Recovering Failed Projects

What does a project failure mean? For the project manager, a definition can be not meeting the triple constraint criteria: scope, cost and time. On the other hand for the customer is more important the business value delivered by the project. Therefore the business value along with the triple constraint are defining the project success or failure criteria.  

There are several reasons for a project failure. Most of them are related to the:

• Requirements: missing, incorrect or ambiguous requirements, lack of stakeholder involvement in the requirement definition.
• Enterprise environmental factors: Improper processes to which the project must comply, lack of support from the top management, etc.
• Resources: not enough or lack of ressources, high turnover rate, not the right resources.
• Project Management: unrealistic estimates, tight schedules, scope creep, communication issues, lack of stakeholder management, lack of the risk management, wrong assumptions, wrong type of contract.
• Technology: Not the right technology, usage of immature technologies

There are 4 steps for fixing a project: 

1. Understand the project. 
2. Audit the project 
3. Find trade-offs and prepare a recovery plan. 
4. Align trade-offs with the stakeholders.
5. Fix the root causes of the issues which caused the project failure. 
6. Deliver according with the recovery plan.

1. Understand the project

       The first step in recovering a project is to understand the project. Thus you have to:

• Check the project history
• Determine the project objectives.
  Determine the business needs.
• Determine the assumptions and constraints
• Make a stakeholder analysis (Who are the stakeholders? What interests do they have in the project? How is their influence in the project?).
• Understand the company processes and their impact on the project. 

2. Audit the project 

In this step you have to find an answer to the following questions: 

• Where is the project staying from the point of view of schedules and costs? How big are the variances? An answer can be given using the earned value calculation (assuming you apply a classical project management) or a release burndown chart in the case you are using an agile methodology as Scrum.
• Is the current scope still valid?   
• What is the priority of each feature which needs to be delivered? You should be able to set priorities at least at the following levels: high priority (must have), medium priority (nice to have), low priority and not needed.
• How the key stakeholders (customers, users, top management, development team) are seeing the project? Are they happy with the project? If not, what is the reason? Furthermore, are there powerfull stakeholders which are opposing the project. Is there enough support from the project sponsor?
• How does the issue log looks? Are there old unresolved issues? The issue log, if a such issue log exists, can provide valuable information about day to day project work.
• Are there people issues in the project? Are the team members motivated? Do you have the right people in the team? How is the team's work-life balance? How is the team morale? You have to involve here the full team.
• Is there any risk with major impact occurred? Does the project have any risk management proceses?
• How is the quality of the deliverables? Are there any quality management processes embraced? 
• Are the company policies and processes appliable to the type of the executed project?   

You might need to consider other areas, as well. But after finding an issue you have to conduct a root cause analysis.

3. Find trade-offs and prepare a recovery plan

After auditing the project, you might discover that the initial targets of the project cannot be reached without to do some tradeoffs. In simple situations you can fix the found project issues and then try to reach the initial goals by doing a „fast tracking“ of the remained work packages (execute the work packages in parallel and not in sequence) and by „crashing“ (put more ressources on the work packages located on the critical path). But in complex situations you might need to do much more. Thus in this third step, trade-off phase, you have to: 

• If the scope is changed, plan to deliver the new scope.
• Prepare the trade-offs related to the scope. In the previous step you prioritized the remaining features/work packages as: high (must have), medium (nice to have), low priority and not needed.
• Determine what is more important for the customers. Can the budget be increased? Can the schedule be extended? Can we still achieve a higher business value with a smaller scope, while keeping the same cost and deadlines? 
• Determine, prioritize and plan the steps to be done in order to fix the root cause of the current situation.
• Determine the new risks, reassess the old risks and prepare a plan to deal with them.
• Assemble a recovery plan.

4. Align trade-offs with the stakeholders.

In this step you have to get a buy-in from the stakeholders for your recovery plan. If it is it still possible to save the project, you have to sincerely ensure them that the situation can be fixed and you have a plan for fixing it. The customers shall agree with the proposed trade-offs. You may:

• Negotiate with the stakeholders a smaller scope, for example without the low priority features.
• Negotiate an increase of the project budget.
• Negotiate an extension of the project deadlines.
• Negotiate a combinations of all from above, but each of the variables to a lower extent. 

The recovery plan will be updated according with the result of the trade-off negotiations. 

5. Fix the root causes of the issues which caused the project failure.

Now that you have an approved recovery plan, you can start to fix the root cause of the issues which caused the project failure. You might need to:

• Discuss the learnt lessons with the team.
• Present to the team the agreements reached with the stakeholders.
• Add, remove, train team members. Start building your team. 
• Change the way how the project is managed.
• Improve the processes which are governing the project (related to change management, quality, risk, type and extent of the project management processes).
• Allow the right level of stakeholder involvement in the project. Fully engage the sponsor and other important stakeholders to secure their support for the project.   

6. Deliver according with the recovery plan

In the last step, the team shall work to deliver the project deliverables according with the recovery plan. But this time the project will be under a higher scrutinity and you, as a project manager, have to:

• Enforce the new agreed processes. Check their effectivity periodically, propose and apply improvements.
• Measure regularily the project progress against the plan and execute corrective actions in case of variances.
• Do a "Fast Tracking"  of the work packages or "Crash the schedule" to win time.  
• Perform risk management.
• Solve the issues timely according with their priority.
• Ensure an efficient communication with the team and the stakeholders.
• Manage the stakeholder expectactions.
• Build and motivate the team. Insulate the team from the external pressure.
• Use an issue log.
• Measure team performance.
• Create forecasts.
• Asses the quality and apply preventive and corrective actions.   

In conclusion, recovering a failed project is a complex activity which requires audit, stakeholder negociations, replanning and a lot of support from the stakeholders, especially from the customers and top management. For any project have to be done periodically sanity checks to discover as early as possible the signs of a failure. In that case, corrective and further preventive actions have to be done immediately. If done too late it's not possible to guarantee that a successfully recovery can still be achieved. 

Rollout Planning of the Enterprise Software Systems - Important Considerations.

Usually the rollout of the enterprise software systems includes 3 phases: pre-deploy, deploy and follow-up support. The planning is done in the pre-deploy phase and its scope includes the feature implementation and activities to be done in the deploy and follow-up phases.
Before an enterprise software system is fully rolled out in production, the deployment will be done in the following environments:

• The sandbox deployment: Isolated from the production environment, the test data are copies of those from the production environment.
• The pre-production deployment: It is the next step after sandbox deploy, it is similar with the production environment, but the hardware used is isolated from the production environment. The production data are mirrored to this environment.
• The pilot deploy: It is a deployment in a real production environment, but it is done only to a small subset of users. Thus major issues will not have a high impact. Ideally the pilot deploy environment will be a department placed at a single location.

It is very important to prepare also the post rollout activities; the follow up support phase. In this stage you must have already available a well established help desk, a change management system, user guides, trainings and FAQs.   

The rollout planning has to consider the following aspects:

• Plan the implementation of the functional and non-functional requirements. The rolled out  system has to fulfill the functional and non functional requirements of the users. Therefore, together with the user, it must be done a gap analysis to discover the still needed requirements to be implemented or the implemented features which do not fulfill the requirements.  Furthermore since every deployment environment may be different, extensive configuration and testing might be needed and correspondingly planned.
• Schedule the deliveries: After being ready with the functionality implementation you should deliver the software to the users. The delivery has to be carefully scheduled. Usually it will be done in stages to minimize the risks for the users. For example firstly the software will be rolled out and tested in a sandbox environment , than in pre-production, than maybe you will do a pilot deploy. In the last step the software will be rolled out in the full production environment.
• Plan for trainings: The users shall be able to learn how to use the rolled out system therefore you have to plan the trainings. A training plan will contain the users targeted by the training, resource needs for executing trainings, their schedules, and the effort needed to prepare the training. Note that the trainings will be done not only in the deploy phase, but also in the follow up support phase. The training materials has to be started latest when the software is deployed in the sandbox environment and to be finished in the pilot phase.
• Create a change management system: It is needed for channeling the user requests for new features, for changing already implemented functionality or to report defects. It has to be available latest when the first deploy is started.
• Organize the support: A proper support is needed both in deploy and follow-up support phase. Therefore you have to plan for creating a help desk. The help desk shall be available latest when the deployment is ready.  In order to reduce the support amount given by the help desk team, you have to train so called “Key Users”. They are part of the user team and will serve as a first level support.
• Do a proper risk management: Risk management activities must be planned because a lot of things can go wrong at a rollout. For example the software might not work at all, might have a bad performance, does not fulfil the user requirements, might not be compatible with the infrastructure. Furthermore you might encounter security issues or the features might not be obvious for users. If you already started with the rollout and a proceeding it is no longer possible you must have prepared a rollback plan. The rollback plan will allow you to restore the state of the system to that state before the rollout.

The enumerated planning activities are applying to the rollout of the most enterprise systems. However each project has its particularities therefore additional activities have to be planned.

Why the project management for international projects is different?

In order to secure the success of the international projects, the project manager has to consider the project particularities in choosing the project management activities.  But where are the differences?

First of all, the teams are distributed. This alone has consequences for the communication effort, relationship between teams and the way how the work packages are designed and assigned. Since the teams in international projects are distributed in different countries, there are further cultural, language, religious, political differences.   

               In an international project, there are significant cultural differences between different project locations.  Culture is very important, because it has a high impact on the work/task attitude, communication approach, timeline attitude, teamwork, leadership, etc. According with my experience, this is one of the most important factors to be considered in managing an international project.

               Usually an international project is executed in locations situated in different time zones. Therefore the window when the people can communicate directly can be very small. For example you have from West Europe with India only 4-5 hours available, but from US is even worse.        

               The language differences also have a large impact on the project. Your project can use a common language for the project, but in most of the cases it will not be the native language for all the team  members. Accent differences, lack of the language skills of the team members will heavily impact the effectivity of the communication. 

               Most of the international projects are undertaken in very large companies, the project is spanning several organizations and departments. You have to consider that each of these have different interests not always aligned with your project.

               The laws and the regulatory requirements are different in each country, thus you might need to consider that for your project activities (for ex: reporting requirements, working time, the handling of sensitive data).

               In an international project the technical infrastructure at the remote locations can impact your project. For example in some countries the internet connection is still slow and there are often power supply interruptions. Furthermore the kind of technology used at the  project sites can be different and not familiar for all the team members.

               Political particularities at the different project sites should also be considered. For example during the “Arab Spring”, in Egypt, the internet connection was shouted down for a couple of days, thus the communication with the offshore teams in Egypt was almost impossible. 

               In order to succeed in an international project, you must adapt the management process to the differences enumerated above. Some activities to address them are named in my previous blog article:  “Best Practices in Managing Project with Distributed Teams”.

Best Practices in Managing Projects with Distributed Teams

We speak about distributed teams when the project teams are located in different geographical locations. Having distributed teams brings advantages as reduced costs (especially in offshoring) but also a better usage of the talent pools from different locations.

Unfortunately there are additional risks in such projects. Most of them are caused by the communication issues and cultural differences.  Bellow I will list and describe some best practices to avoid or to mitigate those risks.

• Choose a management style which is compatible with the culture of the teams. For example you might need to micro-manage in south-asian cultures, but in western cultures you need to allow the self-management of the teams. 
• Understand cultural differences of the involved teams. This is extremely important when you have offshore development teams.  Everything might depend on it: management style, communication, the way how the teams can be motivated, team stability, etc. 
• Reduce coupling between sites. A remote team shall be able to implement a task with minimal help from other teams. That’s important because the communication needs are much bigger in comparison with the colocated teams. The communication issues are accentuated when the teams are located in different time-zones . Furthermore the effort to coordinate the development effort across sites will be substantially lower when the tasks across sites are proper decoupled. 
• Plan for more coordination effort between sites. 
• Dedicate more effort for the verification and validation of the deliverables. Verify and validate often! Due to the communication issues or cultural differences can happen that a task is not correctly understood or does not meet the quality standards. Therefore plan for a bigger testing team, adopt an iterative development methodology with a short release cycle.   
• Create a shared collaboration platform. Use a distributed revision control and source code management system (ex: GIT, Subversion, etc), distribute information on platforms which are available to all teams ( ex: WIKI, Sharepoint, etc) 
• Use appropriate technologies to improve communication between project sites (messengers as Lync, telephones, live meetings). The communication technologies have to be compatible across sites. 
• Plan for social activities to increase the cohesion of the teams. As an example plan for more travel between project sites, execute very early team building activities. 
• Plan for more formal communication. For example, due to the communication constraints, you need to better specify the requirements or the work packages. 
• Maintain visible an overview of the project organization. Every team member shall know who to contact in order to solve a problem. 
• Improve language skills of the team members.. 
• When planning meetings consider the time differences between sites. For example do not set up meetings at a time when is late evening or night at a remote location.

In further articles I will add more details to some of described best practices. The projects executed with distributed teams are more difficult to manage, therefore a proper understanding of these best practices can improve the project outcomes.

Communication Plan. Do you have one?

    The statistics show that a project manager spends more than 90% of the working time communicating. In addition, a poor communication is considered a common cause for the project failure. Therefore it is very important to have a good communication in your project.

    But how to ensure that the communication is properly done? A good idea is to do some planning for your communication. The plan shall cover what information to distribute, to whom, when, how and how often you need to distribute an information.

    In the first step you need to determine what is needed to be distributed and to whom. Thus you have to determine the project stakeholders and to analyze what information do they need. This is the most complex step and requires a lot of attention.

    In the next step you have to determine when and how often you have to deliver the information. That is also dependent by the stakeholder's needs. For example you can send to the upper management or to the customer an weekly report, other stakeholders may be notified only when a milestone is reached.

    Very important is also the modality of information distribution. Thus in some cases you have to use a formal communication (written or verbal) and in other cases an informal communication (written and verbal). The choose between formal and informal communication is dependent by what you need to communicate and to whom you communicate.

    Also the communication technology is very important, especially in the projects with virtual teams. An important factor in choosing the communication technology is the urgency of the communication and the availability of the technology.

    Not many project managers are using a communication plan. Maybe for a smaller project with only a few stakeholders, a communication plan is not compulsory. But for a medium to large project, a communication plan is essential for the project success. A larger scale project has a big number of stakeholders and not providing the right information at the right moment can have important consequences and is a potential source of conflict.

Action Item List

    An action item is a small task, activity or an action which have to be executed by the project manager, a member of the project team or any other stakeholder. All over the project life cycle you can determine that action items have to be performed. In many cases you determine them during meetings, discussions with stakeholders, but also by logical deduction.  As a project manager, you have to assign them for execution and , in addition, you have to track them.  In a small project, your memory might be enough. But in a larger projects with many team members and a lot of other stakeholders, you need to document them properly.
           
Personally, I manage the action items in a tabular document (see example) with the following columns:

1. ID:  an incrementing identification number
2. Action Item: describe the action which needs to be performed.
3. Status: can be „Open“ if the action is not yet done, or „Closed“ if the action is resolved.
4. Creation Date: Represent the date when the action item has been issued.
5. Due Date: The date until the action item has to be resolved.
6. Urgency: Depending by the urgency of the action item this field can have the the following values: Showstopper, High, Medium and Low.
7. Responsible: the person assigned to do the action. I recommend to assign only one responsible per action item in order to have a clear ownership of the action item.
8. Comments: You can add here different information about the action item. For example you can give more details about that action item, add information about the status, problems in solving it, etc.

    The action item list is managed by the project manager and I prefer to place it in a document management system as for example SharePoint. Since a document management system is corporate wide available, each team member can check for his action items and update them accordingly.
    
     How the action items are communicated? Those which are issued during a meeting are communicated along with the meeting minutes.  In the other cases, they can be informally communicated.  

    Very important is to track the status of the action items. Most of the project managers are checking the status of the action items during the status meeting.  Personally I check them one time in a day, sorting them by the due date and urgency. Case by case, I escalate them to be resolved.

Best practices for creating a Work Breakdown Structure

In an earlier article, I described why a WBS is so important. But in order to be a usefull tool, you shall respect some best practices. I will discribe bellow some of those.

1. Use a top-dow approach. Begin at the project goal level and break the work successively to lower levels of definition.
   
2. Create it with the input from domain experts and team members.
   
3. Do not include any work which is not part of the project.
   
4. Cover the entire scope of the project at least at the upper level of the WBS (In a iterative development aproach, the WBS is developed iteratively, thus the entire scope will be only at the end of the project available). But in early phases, the entire scope of the project can be covered in the in the high level WBS components.
   
5. Each component of the WBS, excepting the highest one, is a part of the parent WBS component.
   
6. The lowest level of the WBS shall have the following properties:
   

• It is possible to estimate its need for ressources, duration and costs. Aggregating this information for each lowest level work package you can calculate the ressources, duration and costs for the entire project.
  
• The start and the end of the execution can be clearly defined.
  
• It's realization can be outsourced. That is true mainly for work packages to an upper level in a WBS. The outsourcer can further decompose that work package.
  
• It has a deliverable or a clear part of it. The deliverable is a prove that the work package is complete.
  
• It can be completed within reasonable time limits. There is no universally accepted rule regarding the length of an work package. However, it  shall not exceed 1-2 weeks to complete.
• Specific to the software development projects, it can be executed by a single developer.