Change management

Experienced project managers know that change is inevitable and there are many consequences of failing to manage project changes. Some of the critical consequences are;     

• Scope creep
• Cost and budget overruns
• Project delays
• Poor quality of the project deliverable
• Often the project team performs incomplete work for the project deliverables
• Stakeholders express concerns about the project manager’s ability to manage the project

So the problem is not the change itself but how the change is managed. There are many benefits of managing changes properly such as increased stakeholders’ satisfaction, improved quality of the project deliverables, opportunities for the additional project work etc. There are basically three types of changes that need to be addressed in order to ensure a project success. These are; 

Technical changes: These are the internal modifications in scope of the work of the project. 

Market changes: These are changes that are inevitable due to external market conditions such as competitors’ product or service enhancements or regulatory changes. 

Contractual changes: Changes that are made on the contract with the stakeholder or supplier. These changes include but not limited to the terms & conditions, scope of work, requirements, schedule, costs etc. 

The most important function of a project manager is to prevent uncontrollable changes. Uncontrolled and unexpected changes in user /stakeholder expectations and requirements as a project progress always negatively impact a project. This is known as scope creep. Many times new features are added to the project with a wrong assumption that one small feature will add nothing to cost or schedule. This unplanned addition is called feature creep. 

A change in the one of the  triple constraints of a project has an impact on the other two. The key is to find balance between the need to manage the scope of the project against the agreed requirements, cost & schedule. 

Impact Analysis for Change Request

Changes may negatively or positively impact a project. When a change request is made, you as a project manager need to analyze the same in order to evaluate whether it is within or outside the scope of the original project requirements as well as how it is going to impact the three constraints of your project namely scope, schedule and cost.  Impact analysis is the most important step to effective change management procedure.  Your impact analysis should not only reveal the impacts of changes on the above three project constrains but also it should provide you the essential information related to the effects of changes on people, processes, quality of the project and on the operation of your company.  By implementing proper impact analysis procedure you should also be able to evaluate the overall project risks, how the change is going to alter the existing risks, whether or not the project is going to face new risks and the cost associated in managing those risks.    

Every organization has its own way of doing things and in most cases structured processes are available.  You need these organization process assets that may or may not have formal procedure for impact analysis. However, the following guidelines will always help you understand essentials of impact analysis procedure and how you can diligently implement such procedure. 

Step one: Do you have the money? 

Every work involves some cost and the impact analysis of change requests also requires some budget especially when it is a large change request.  Do you have the contingency budget to cover the cost or do you need to request the project sponsor / customer to pay for the added cost? 

Discuss this with the project sponsor and always come up with adequate numbers so that you can properly make formal presentation to the project sponsor and request the extra fund that you need for the impact analysis. 

Step two: Determine the reason for the change. 

Why the change request is made in the first place? Can you avoid it / defer it or is it inevitable? Determine the business need for this change and how the change is going to benefit the project, the process, the work product, the quality, the stakeholders and the organization.  Also review the Change Log to determine if the amount of change is excessive on the project. If change is certain, determine what is the priority of this change in comparison to other changes, such as current requests and requests being implemented? 

Step three: Analyze the impact on triple constraints. 

Scope: Determine the impact on the overall scope of the project, Work Breakdown structure (WBS), Product Breakdown Structure (PBS) and Resource Breakdown structure (RBS). You need to find out information in details by identifying the product features that would need to be added, changed, or deleted and any sections of the PBS, components of the WBS that would also need to be added, changed, or deleted and also the resources that would be required to implement changes and how it is going to alter the RBS. 

Also you need to identify any changes that need to be made to the agreement with the customer or any vendor or subcontractor.  

Cost: Identify any changes that need to be made to the cost management plan and the overall financial plan. Who is going to pay for the added cost? Find out whether the change will be paid for by an external sponsor. Similarly like scope, you also need to identify any changes that need to be made to the agreement with the customer or any vendor or subcontractor.  If subcontractors are involved, determine whether the change is going to impact the subcontracting cost. Refer to your organizational process assets and guidelines to ask for the additional cost or price for the change from the procurement department. Your impact analysis report also should highlight the financial benefit to the project and the financial benefit to your organization. You should also document other benefits such as improved schedule, better performance, lower risk, future opportunities, stakeholder satisfaction, enhancements to the organization’s intellectual capital, and technological advancement. 

Schedule: Your project needs to be completed within time otherwise you are invariably going to incur cost overruns because the project schedule is linked to scope and cost. Estimate the time required to define and plan the proposed solution and the time required to implement the proposed changes. Evaluate the changes to the milestones and to the critical path.  Also identify the changes that would need to be made to the Work Breakdown Structure (WBS), the project management schedules and the milestone lists. Determine changes to the contractual schedule with the subcontractors. Also determine the impact of the change outside the delivery organization by identifying any changes that would need to be made to the Agreement with the sponsor and with any subcontractors. 

Step four: Identify dependencies 

Your various project activities are interwoven by complex successor relationships.  Identify other tasks that are dependent on this change being approved. Also determine the predecessor relationship and prioritize the tasks that must be completed before this change is implemented. Also it is equally important to determine the resource dependencies and how you are going to use resources for this change.  And finally, you also need to identify other dependencies such as market conditions, government regulations etc. 

Step five: Analyze the risks 

Analyze the risks that are associated with this change. Identify all the risks qualitatively and quantitatively the project is facing or will face in the future due to this change. Also identify threats that are associated with this change. Threats would include changes that have possible negative impacts or risk. Even a small change might include a high amount of risk. 

Step six:  Determine the impact on the Project management system 

Identify and list all the changes that would need to be made to the project procedures description or to the project decision structure. Identify changes that would need to be made to the communications management plan, the project quality plan, the risk management plan, the technical environment plan and overall the project management plan.  Also determine the costs to update the project management system.  

Step seven: Document your findings  

Properly document all the results of your impact analysis. Prepare a detail report for the change control board to approve changes. Follow your organizational process assets and procedural guidelines to document reports of the impact analysis. When the change request is approved by the change control board, the change order is created. Identify the project documentation, including the project management system documents, which must be changed or updated to reflect the approved change. Update the financial management plan when a change has a financial impact. In order to show the changes to work items or completion dates, update the project management schedule, operational schedule, and the work breakdown structure. Most of the change request is associated with changes to the scope and in such scenario update the project definition, deliverable definition, or other documents that control the project scope.  Also update the technical specifications, the test plans, the quality management plans.  A great deal of a project manger’s time is spent on communication.  With every approved change request, you need to prepare new reports or arrange new meetings and that is why it is imperative that you also update the communications management plan.  Most important document update is the updates on the risk register. Document all the qualitative and quantitative risks and also include updated risk definitions due to this change.  

If the change control board approves a change request then you need to create change management work product that will consist of change request templates, instructions for the changes or the change order and a log to record changes.  

Implementation of change management also equally important and things may go wrong if a project manager fails to properly implement change management. That is why it is important that the project manager work cohesively with the team as well as with the change control board.  

Also another important factor to remember is that the impact analysis for multiple change requests may not reveal hidden costs. In such scenario, it is always recommended to rely on expert judgment.  

Identify stakeholders and bring them early. Stakeholders who are found later will make changes and could cause delays. Any change that is made later is harder to integrate and is much more costly. Communicate with the stakeholders effectively and on a regular basis. Give a project presentation, list all their issues and concerns, report progress and inform changes and updates to the project management plan. Another important function of a project manager is to prevent uncontrollable changes. Stakeholders have greater influences over the requirements as well as changes in a project. That is why it important to have effective communications within the team and between the team and other project stakeholders.

Let’s try to understand why do you need a communication management plan?

• Communications management plan reduces and mitigates risk
• It provides you clear guidelines on how  you formally  interact with the project stakeholders
• Communication management  plan provides tools to utilize resources effectively
• It gives you the ability to analyze the impacts of various meetings
• It also ensures mutual commitments with the sponsor and other stakeholders
• The Communications management plan clearly documents all the deliverables and delivery schedules
• You should  be able to deliver  the right message at the right time to sponsors so that you can control  rumors and unnecessary work products
• A well defined communication management plan enhances your ability to meet stakeholders’ expectations

A project manager inspires people, shares the project vision with the group and creates a very motivating environment.  Communicate with all levels of the members of your team regardless of level. Communicate clearly your plans & ideas and make sure everybody understands them.

Your communication management plan should include both internal communications and external communications. Your internal communication management plan includes status report, progress report, trend report, forecasting report, variance report, earned value report etc. External communications requirements include types of meetings and reports, existing policies and contractual agreements etc.

Here are some simple steps to create an effective communication management plan.

Step 1: Documents the followings

1. With whom you need to communicate?
2. What deliverables are needed?
3. What media you are going to employ in the communication?
4. When the communication will occur?
5. Where the communication will occur?
6. The purpose of the communication

Step 2:  Document the list of deliverables, the list of stakeholders and your stakeholder analysis for each stakeholder. You need to document communications requirements with the sponsor, with the functional management, the subcontractors and with the team.

Step 3:  Determine the needs for media. Your communication management plan should have a media section where you document the types of media that you plan to use for communications on this project. Document the media requirements to make sure that all stakeholders have access to the particular media or technology that they need for their required communications.

Most cases you will be using the following media types:

• Conference calls
• Fax
• Knowledge repositories available on company’s intranet
• Paper reports
• Power point presentations
• E-mails
• Video conferences
• Instant messages such as AIM
• Electronic files, including zipped files, word processing files, and spreadsheets
• Web sites
• Information stored electronically on company servers
• Project management software such as MS Project
• On line project tracking tools

Step 4:  Document a schedule for the milestones and communication deliverables. You should have a table or calendar that shows your deliverables and other communications time.

Step 5: Determine the assumptions, dependencies, and risks associated with your project communications.

List all important assumptions you considered while creating communications management plan such as all stakeholders speak English or all team members will be company’s full time employees only. This may change the moment you hire contractors.

List all important factors upon which your communications management plan depends. For example, the communication among team members located in several time zones depends on how and when they communicate, what communication media they use and how they distribute reports.  A dependency is an input or output or time-related relationship.

When managing dependencies, confirm that the deliverables are well-defined, within the project scope, and also include a statement of work. Confirm that the schedule and cost are understood by the parties involved.

Identify past, present and potential risks that the current project faced, is currently facing or will face in the near future and list any important risks inherent in the communications management plan.  

Step 6:  Every work involves some cost and in your communication management you should itemize the costs associated with communications. For example, you should have a list of cost associated with conference calls , video conferences, instant messages such as AIM, your and team members time in preparing reports, cost of using other facilities etc.

Step 7:  The final step is to review your plan before you finalize it. Here is a check list of your communication management plan.

• List of your stakeholders and your detail plan on their communication needs
• Organizational type such as projectized, functional or matrix
• Document any geographic or multicultural requirements
• If you are working with a remote team make sure remote team requirements are met
• Document use of technology against your stakeholders’ access and technical skills
• Check to be sure your stakeholders are assigned appropriately to the reports, meetings, and other communications types according to role, level of detail, and personal communication preferences
• Review all the levels of communication and do not overburden stakeholders with too much or too little information

Your communication plan also should include the communication methods such as formal, informal, verbal and written. You communicate internally and externally to the project team and vertically and horizontally within the company. Use the following guidelines for selecting a communication method. However, please remember that every organization is different and you need to take into account your company’s processes and procedures for conducting work and communications.

Formal written:  Project charter, reports to the management, project management plans, communicating between divisions etc.

Formal verbal: Presentations and speeches

Informal written: Notes, e-mails, memos, status updates among team members, online chat etc.

Informal verbal: Conversations, meetings, discussion and often water cooler gossip  

In step 3, we will discuss about project changes and  how you manage a change.

You have been a successful techie for several years. You have been working as a team leader at your current job for past eighteen months and you have just successfully completed a huge in-house software development project. Your project manager just got transferred to PMO with a promotion and you are the natural choice of your company to fill that vacant slot.  The company sends you for in-house project management training so that you understand the company’s processes and follow the guidelines of the PMO.  You are excited but bit nervous about your new role. You have acquired the theoretical knowledge about project management methodology and the company’s processes from the training you just completed but you do not know how to effectively implement them in your project.  At this stage anybody would be nervous as wise men said, “you do not know what you do not know”.

Relax! Here are the strategies to function effectively as a project manager and if you follow my simple albeit effective guidelines, you will be very successful in your new role as a project manager.

Step 1:  Understand top ten reasons of a project failure and proactively plan to avoid them.

Step 2:  A project manager spends over 80% of the time communicating. Have a solid communication plan not just a strategy.

Step 3:  Change is inevitable in a project. The problem is not the change itself but how you manage a change. Learn how to manage changes.

Let’s start with step one: Top ten reasons of a project failure.

1. Poor planning: Planning is the most important step of project management process. Half of the battle is won when you plan well. Coordinate with the project participants and the stakeholders to develop a detailed plan for the assigned project. Involve your project team members in planning and have the team buy-in. Prepare project scope, statements of work, work breakdown structures, task estimates, and specific tasks and milestones. Plan resources and schedule for your project implementation. Proactively plan effectively all anticipated bottlenecks, which include but not limited to management escalation, project prioritization, finding the right trade-offs between the business needs versus technical as well as triple constraints namely; scope, cost and schedule.

 2. Unclear goals and objectives: Many IT projects are elaborated progressively and in these scenarios you as a project manager need to rely on rolling wave planning. Initially the goal of your project may be only partially clear due to a poor requirement gathering in the definition stage of the project and you may not have clear picture of the scope and the schedule.  Defining clear requirements for a project can take time and lots of communication. You need to have expertise in rolling wave planning and that is where you should proactively focus.  You have strengths as well as weakness in this area. Being a technical team leader you can clearly view where the project is heading and you can very well anticipate the technical requirements and the future enhancements but at the same time you do not know how to plan for something that may be the future requirements. The best thing to do in such scenario is to rely on expert judgment.  Find project managers within your organization who have experience in rolling wave planning and seek their guidance. Your strategy should be to combine your technical expertise with experts’ judgments so that you can plan for your project that going to be progressively elaborated.

3. Poor Stakeholder Management: Identify stakeholders and bring them early. Project stakeholders’ interests may be positively or negatively impacted by the project and that is why stakeholders’ influence on the project is the most important thing to consider. Stakeholders who are found later will make changes and could cause delays. Any change that is made later is harder to integrate and is much more costly.

4. Scope creep and Feature creep due to objectives changing during the project: Scope creep refers to uncontrolled and unexpected changes in user expectations and requirements as a project progress, while feature creep refers to uncontrolled addition of features to a system with a wrong assumption that one small feature will add nothing to cost or schedule. Understand project trade-offs and make decisions regarding objectives on the basis of rational insight. Try to prevent project scope and feature creeps by implementing effective scope control methodology.

5. Unrealistic time or resource estimates: Many times project managers makes costly mistakes while estimating time or resources. Always work in a collaborative environment with the team and have the team buy-in and also consult with the project stakeholders as much as possible while preparing the detail project scope statement so that you do not make costly mistakes while preparing the WBS. Also employ effective techniques to estimate the amount of time each activity is expected to take. Be careful not to (common mistake new project managers make) use linear approximation when estimating the schedule For example, if you double the number of developers, you can cut the project time in half. In reality, doubling the number of developers produces a non-linear result.

6. Improper delegation of task and responsibilities: Many times project managers fail to delegate task and responsibilities to the team such a way that it should fit a team member’s job description. Organize the team such way that everybody should work under his/her own specialization so that the team as a cohesive whole performs the work diligently and within time and budget and thus raise efficiency above standard.

7. Lack of executive support and user involvement: Carefully listen to the executive management and the project sponsor and try to find out whether they have reservations about the project. If so, what is their vision for the project and what are their business objectives of the project. Try to work as an interface between the business and technology sides of the company so that you help our company align business with its projects.

8. Failure to communicate and act as a team: Projects sometimes fail due to improper communication.  A great deal of a project manger’s time is spent on communicating. We will discuss more about communication strategy in step-2.

9. Lack of proper risk management: Another potential cause for project failure is the IT managers’ inability to categorize all the risks qualitatively and quantitatively and implement corrective measures. Identify past, present and potential risks that the current project faced, facing or will face in the near future. Carefully and methodically categorize all the risks qualitatively and quantitatively and implement corrective measures. Assign one or two persons from your team as risk owners. These persons identify the risks, discuss the risks with the team and the project manager, find solutions and implement them.

10. Inappropriate skills: In this rapidly changing, technology-driven business environment and the constant changes of technology make it hard to predict skills the IT department will need. Almost all large IT projects require a diverse range of skills. Many teams lack the breadth, and depth they require.  Plan proactively for your resource requirements and make sure that everybody works under his/her own specialization. Have a solid plan for the skills your project requires. Work with your HR manager to evaluate all alternatives, which may include but not limited to hiring contractors, outsourcing, providing training to existing team members etc.

In step 2, we will discuss about communication and how to have a solid communication plan not just a strategy.

Technorati Tags: best-practices, change-management, communication, project-management

Sometimes, you have to break the rules to get things done!

As we go through our lives we are subjected to numerous rules – as kids, as students, as workers and as adults living our everyday lives.  As program managers and leaders, part of our responsibilities is to lay down some rules by which to guide projects, by which teams work together and by which products are built, tested and released.  However, let’s not forget that the reason we have rules is to get us to a destination.   There is a favorite quote of mine which I invoke to remind myself of this principle:

Hell, there are no rules here – we’re trying to accomplish something.  Thomas Edison.

The program manager needs to know when to go by the books and follow the TL9000 (or your favorite development) process and when to let loose and have the team go off and run as fast they can.  I once worked with a program manager (let’s call him Joe) who could not tell the difference.  He was a ‘by the rules book’ type of leader – and that actually got in the way of us getting our jobs done.   We ended up getting to our destination despite Joe.  Here is the story.

Joe was responsible for leading a project on which I was one of the engineering managers.  We started out with a reasonable plan, and had regular program meetings, with status, minutes and action items that Joe would track.  Along the way, two things happened.  Our management wanted us to adopt a new development process.  And, at about the same time, we also had the inevitable ‘technical bump’ in the road that required our attention.  The new process rule required a detailed unit testing plan be documented, and signed off at completion prior to handing off to the QA team.  Joe was focused on tracking this new process requirement and getting the test plan documented.  The engineering team was very concerned about the bump.  Without addressing the bump, there would be no substantial development or unit testing to speak of.  However, Joe had it in our project schedule that the unit test plans would be done by a specific date and tracked that religiously at each meeting.  Joe also had very little domain knowledge and despite the team’s efforts to educate him on the criticality of addressing the problem asap, he continued to focus on the dates and the schedule.  Joe was following his rules book – the established project plan.  The engineering team decided to take matters into its own hands, and we held shadow program meetings without Joe to address the bump and quickly fix the key technical issues that were hampering our progress.  Joe’s rules were getting in the way of work being done.  When the crisis was over, I gave Joe some feedback that he needed to be able to adjust his plans when bumps came along, and bend the rules to meet our most critical goals.  To do that, he needed to learn more about the domain and understand the business of what he was program managing.  However, I hear he still manages the same way. Sigh!

Focusing on the rules and mechanics of program management helps keep things going.  But a good program manager needs to have at least a basic understanding of the domain and be prepared to apply rules or break the rules in order to get things done.  At the end of the day, the customer will not pay if we don’t have a good product, but followed all the rules!

Image: EdgeDonkey

We all have been in the situation where a customer or team member asks to add a feature or upgrade the quality of a certain item. We often agree to do these favors because we find ourselves unable to say “no”—driven by our desire to please or a preconceived notion that we do not have the option to say “no”.

Favors happen on projects because many of us like to help other people. Doing so makes us feel good. It can make us uncomfortable to say no or to make tough decisions. The problem with doing favors is that it can have a domino effect or even start the project on a downward spiral. One favor begets another and before you know it, you have lost control over the project scope, budget, and/or timeline.

The construction industry has made controlling favors an art. Anyone who has ever built a house or has done some remodeling knows that contractors do not do favors. Any requested change is discussed, the work estimated, a cost assigned, and a new timeline approved.

Project managers in other industries would do well to take a lesson from the construction industry. Rather than simply saying no when someone requests favors, make the price tag visible so that the right decisions and tradeoffs can be made. Skillful project management is not about trying to please one person at a time; rather, it is about satisfying the majority of the project stakeholders involved and most importantly to provide customer value. This requires balancing all expectations.

Project management is not a popularity contest.

via Flickr by Bouliqab

Where to Go From Here?

I realize that most of us will never face the challenges confronted by Gene Kranz, NASA Flight Director, on Apollo 13, but the mental exercise is worth doing.  If you haven’t seen the movie, or have seen it and view it as entrainment at the time, I suggest renting it and putting yourself in Gene’s shoes while watching.  You can put yourself through an endless stream of questions:

• Would I have Gene’s mental toughness?
• Would I be prepared to ratchet-up my leadership skills and rally the troops?
• Do I have the knowledge in problem solving and decision making necessary?
• How can I improve my day-to-day leadership, now I’ve seen one of the best project leaders in action?
• Etc., etc. ….

Remember it is a journey of a thousand steps and it starts with just one.

Technorati Tags: Leaderhip, process

via Flickr by dbking

Rallying the Team from a Bump in the Night

For the rare situation where the project plan comes to an abrupt, premature end or dead stop, it is your time to show everyone what real leadership is.  At this point the whole team, and more, are looking for someone to rally them and provide direction on how to proceed.  Let’s not confuse direction with providing detail instructions on what to do (micro-management).  What’s needed is leadership and a process for the path forward – everybody following and moving in the same direction.  It is the followers that will be doing the work and it is you ensuring the process needed to accomplish it is established and communicated, including when and how decisions are made along the way.  Here is a general outline of the flow:

Step 1: Bring the team to a common agreement on the points of the situation:

• The facts
• The assumptions
• The selection criteria for solution alternatives

Step 2: Organize the team’s creativity effort for solution development

Step 3: Monitor the development process and make adjustments

Step 4: Converge to a set of solution alternatives

Step 5: Make the decision and act on it

I’m sure at this point there is at least one doubting Thomas among the readers.  When asked whether creating an Apollo 13 disaster recovery process on the fly and managing to it was a waste of time, Gene Kranz indicated the opposite was the case, it saved time because it gave the team the needed focus.

I wish you the best of luck, if you’re ever experience a bump in the night,  in pulling another iron out of the fire and getting your project back on track; may you have the same success as Gene Kranz.

Technorati Tags: Leaderhip, process

via Flickr by krossbow

Process for Handling the Dips in the Road

The majority of unexpected situations that hit a project during its execution are dips in the road to closure; a leader can certainly prepare both themselves and a process for the team, to deal with these.

As the project leader you own the solution/decision process, like any of the other project processes, and are responsible for:

• Understanding the organization’s  decision culture and its implications for affecting a final solution
• Ensuring the process is viewed as fair, legitimate and transparent by the participants, in order to maintain an engaged and cohesive team, through commitment and shared understanding
• Driving the team to converge on a final solution; not personally creating the final solution and selling it to them
• Sharing with the team what the process is and the role they will play and what your role will be
• Fostering a creative environment for solution development

The bottom line is: People want to be engaged and to have their positions heard on any given issue; then, they want a choice to be made, so the team can move on.

Technorati Tags: Leaderhip, process

via Flickr by woodleywonderworks

Who is Solving the Problems and Making the Decisions?

The question on the table is, will we have the right person(s) solving the problem and/or making the decision, when needed?

The volume of problems/decisions seen by a project is probably somewhat pyramid in shape, with the bulk lying with individual SMEs and, hopefully, precious few with the organization’s senior management team.  From another perspective, an inverse relationship exists between the problem volume and the number of people and/or organizational levels involved.  Involvement appropriate for the situation makes for an effective use of resources within the organization.

So, who is the traffic cop?  You are; the project manager (leader).  How do you know what is right? There are two key issues that need to be considered:

• The composition of participants – Who needs to be involved because it either affects their area of responsibility and/or makes use of their expertise?
• The environmental context of the situation – What are the implications of the situations final resolution, relative to the project outcome, the well-being of the organization, etc.?

My assumption in the previous post was you had a strong, cohesive execution team already in place, which implies the team uses the project meetings to openly discuss challenges (and waste little time on success status) and readily shares information.  As the leader, your role is understand how each challenge/situation is being handled from a process perspective; not necessarily technical content.  In terms of the process, it need to be a hub-to-spoke communications, with you as the hub.  Unlike the solution/decision communications model, which should be point-to-point among the active participants. This is not to imply you can’t be a participant in the technical discussions, it just means in order to lead your focus has to be first and foremost the process.

It boils down to active listening.  Is this person talking to me about project process or technical content? Even if they are talking about the technical content, is there some implied process issues?  Remember, getting the project technically correct don’t necessarily bring it on time, under budget and aligned with the organization’s strategy.

Technorati Tags: Leaderhip, process

via Flickr by James Jordan

Are you prepared to cope when things go bump in the night?

As project managers we have become proficient in transforming the project charter (in whatever form we get it) into a project plan (hopefully, including some risk management) and then charging through plan execution to closure.  But, what happens when thing go bump in the night during execution?  Have you prepared for a discontinuity? I’m talking about the metaphorical equivalent of the plan dropping off the edge of the earthquake damaged bridge.  More specifically, something like Apollo 13, an onboard explosion that instantly trashed the entire project’s plan and requiring some heavy-duty problem solving and decision making to create a new plan in short order (if the astronauts are to make it back alive).  NASA didn’t have this scenario in their risk management plan, much less having a mitigation plan.  Yes, I know this is an extreme example and most of us don’t work on projects where people’s lives hanging in the balance, however, some of us have managed projects were the organization’s future is at risk.  It is only when we are prepared for the worst, or at least something worse then you will ever see, does everything else seem easy.

Now that I have your attention by setting the extreme boundary of the topic, let’s take a look at our project teams and think about a few thing that may be taken for granted or just not considered, at the outset.  Things that may help us shine, even in everyday situations, because we are mentally prepared.

Project Management 101, with the PMI PMBOK® as its underpinning; have taught us the methodology for putting together a good project plan, executing that plan and bringing in a successful project.  No problem, with a good plan and team of SMEs (subject matter experts) we can sleep at night.  Right?  Sometimes.

Even with a solid project plan created through your competent leadership and active participation of an outstanding team of SMEs, have you ever stopped to think about all the problems that get solved and all the decisions that get made in the course of executing the plan, most of which were never considered or documented as part of the planning process, even if you did risk management?  Some are at the day-to-day level of individual SMEs, while others may require the involvement of senior executive management, and all points in between.  What will the effect of any one of them be on the overall project effort and outcome?  Some are constraint changing, other plan stopping, and many go unnoticed.

In the posts that follow we will consider three items the PM should be concerned with:

• Are the problems/decisions being addressed by people with the right level of responsibility and/or expertise?
• Does the project team have a process for problem solving and decision making to handle the daily dips in the road?
• Are you and the execution team ready for a bump in the night?

Needless to say, this discussion is situational, dependent upon the size of the project, its complexity and it criticality.  On the higher end of the scale, like the Apollo 13, it is more important to formalize a process for problem solving and decision making.  However, even on the lower-end of the project spectrum, there are always benefits for the PM to have at least thought through some possible scenarios.

Technorati Tags: Leaderhip, process