Flying under the Radar

So often consultants enter a new client’s office with our project bag of tools and associated project language.  We usually begin by telling our client “how to do” project management, work plans, status reports, issue tracking, issue escalation, governance, change request process, escalation process, timelines, milestones, project deliverables, the lifecycle , communication plans, process improvement, Six Sigma, toll gates, etc”.  By the time you have finished your clients’ eyes are crossed, their heads are spinning and the room is filled with the sound of silence.  If I was the client I would run out of the room screaming, “STOP”.

How about an alternative approach that is “just do it”?  I know Nike is famous for bringing this simple approach to light.  Let’s say it is time that I get into shape and I want to start a jogging/running program.  The simple approach is to get a pair of running shoes that are comfortable and put one foot in front of the other.  Start slowly, short distances and gradually OVER TIME speed up and run longer distances. Don’t over do it and if you hurt, then rest and recover – a very simple, easy process with easy to follow instructions.

The other approach to start a running program is to research all the running shoes available to ensure you get the “correct” pair.  Then you need to find the answers to all the technical questions. Do I pronate? Do I need orthotics? Am I a heal striker or toe runner?  How should I hold my arms and hands?  What should be my stride length?  By the time you would get through all of that you may want to take up Ping-Pong.

So what approach can we take with our new business client?  Here are some thoughts:

• Define what you initially want to get done, say in the next 30 days (For example: the project goals/scope and interim work plan)
• Keep a list of questions (potential issues) that need to answered
• Identify who, when and how we keep the right folks (Sponsors, stakeholders, project leads) informed about how/what we are doing

I think this is enough to start. Then do it.  Bring in templates and “project speak” only as needed.  Keep the documentation simple and fact-based. I am not suggesting that you not follow the client’s standards if they already exist.

A next step would be to look at what you want to do in the next 30 – 60 days. And repeat the steps above.  As you hit the next 60 – 90 days you should have a viable plan that you can manage to and a process to review the progress, the financials, etc. and you will have introduced “project management” without your client knowing it!

In conclusion, I think if we remember that the tools are not the focus, it is the work, we will have more success and a very satisfied client.

*Contributor – Bob Metzler, Managing Director

Download PDF

Why PMOs Get a Bad Rap

You want to paint a picture: Did you get the “paint by numbers” with a predefined picture and stay within the lines or do you start with a creative stroke of red paint on a white canvas?

All too often we see PMOs that are built without following the same practices we would use to begin a project. Instead, they are built from a prescribed method without consideration for the problem being solved. This is where the trouble begins and the “bad rap” is attached to the PMO. Let’s look at some reasons why PMOs get a bad rap and what you can do to build a successful PMO for your organization.

Depends on What “It” Is

For organizations that have a mired of project investments, governance and controls are a must have. There is an immediate propensity to build “it,” without a consideration for what “it” is, how “it” will perform, the benefits/merits and success tracking of “it”. A PMO should never be built because it is vogue, but rather because it is essential to the success of an organization.

Before you build the PMO, identify the problem and the “appetite for change” (how much change can be introduced and over what period of time).

Gaining clarity on what “it” is will get you to a viable solution, and “it” typically does not come out of a book. An organization’s real needs should always drive the PMO build out.

Using Project Management Processes to Design the PMO

The design and build of a PMO requires the same due diligence that we would use to plan and execute a project. One of the current trends in building a PMO is “build it and they will come”. In reality, the PMO is built and quickly becomes a burden, so why are we not utilizing project management processes to define/design our PMO?

A large Telecom purchased a step-by-step PMO guide at a discounted rate that included templates and online training. After implementation, a PMO Administrator would create a “one-size-fits-all” compilation of reports from data that was collected monthly from the project managers. The Administrator would then email the reports to the leadership team on the requested timeline. The reports rolled up identifying the project portfolio, highlighting “at risk” items in red. 

The PMO team began to realize that a long list of PMO-generated reports were not of any use to the leadership – they were outdated and not being read. The PMO was already getting a “bad rap” by the very people who once advocated its importance.

This particular PMO was created as a new box on the organizational chart, provided some “silver bullet” tool, to find that it has become an administrative ball of yarn that quickly began to unravel. 

Define the Problem

The PMO should start with a defined Charter that identifies the business problem the PMO is supposed to solve, ties to the strategic vision of the organization and communicates a clear vision that will be embraced across the organization. Success measures should be defined as goals and measured/reported.

If you don’t define what you want then you won’t get what you want!

What are the Requirements?

Requirements are essential building blocks to answer the question, “What do we want the PMO to provide?” In the Telecom situation noted above, the organization jumped in headfirst with a solution. While the requirements themselves are not the solution, they enable us to lay the foundation for the PMO roadmap and subsequent success measurements. In this scenario, a gap analysis to determine the “as is” and “to be” was not completed. The gap analysis is a technique to identify the current situation and the future vision, which helps to uncover the people and process aspects and change impacts. The purported “best practice” methods/tools may not be addressing your organization’s needs.

Why Does Our PMO Not Have Any Clout?

Once you have gathered the requirements, put together a roadmap and start the execution, this is when we often see the PMO begin to lose traction. The PMO team may find itself asking, “Why do we not have any influence?”

The PMO is about people and process within your company’s culture. There is no cookie-cutter approach based on a new organizational chart. The PMO needs to have defined resource capabilities, be clearly accountable to its stakeholders and not create fiefdoms. Here are a few considerations that will help put the punch in your PMO; we call this the “accountability factor” of your PMO.

By establishing what the PMO will or will not provide and the roles and responsibilities of everyone involved, you prevent the creation of false expectations. The importance of the PMO should be documented and communicated (and not by the PMO). Interactions with vendors, contractors and consultants who work with the PMO should also be identified, and clear communications procedures established.

It is essential that the right people are in place to make the PMO successful. This includes transitioning and maintaining continuity so the PMO can increase productivity and measure success.

Is the PMO information relevant to support an escalation path where senior stakeholders can act and disposition it? If not, why? Status, risks, issues and financial information should be a factor in ongoing decision making across the PMO portfolio. The governance process should be established for decision making and handling change control for the PMO. For example, if status reports are provided and no one reads them is it because there is no value to them, they lack credibility, format is too complex or are they outdated? Where is the value to the recipients? Creating and reading reports takes time, and time equals money. The PMO has the accountability to address the lackluster interest in the reporting. It goes back to the basic premise that if no one looks at the report then why was it created?

One major PMO benefit is standardization, which includes reporting, processes and practices. Standardization also includes the execution and documentation associated with Risk Assessments for not just project risk, but also deployment risks. Having a standard risk evaluation ensures stakeholders receive the information the same way and can help with risk mitigation.

The PMO may have lost its punch because no one knows where the information is. To overcome this barrier a process for documentation should exist. This would be the guidelines for the centralized repository with required project information.  A project library of key information will become critical for auditing and provide proof of SOX compliance.

To be truly successful, the PMO must continually go back to the definition of what stakeholders need for information and decisioning purposes. A PMO Communication Plan enables the team to understand and address who, what, when and how the stakeholders are engaged.

Understanding stakeholder information needs begins with asking the right questions. For instance, does this group want to distinguish Business as Usual, Regulatory/Compliance, Merger projects?  Do they want to monitor success metrics and are they interested in determining deployment approaches? Too often, we forget who the clients are.

Stake in the Game – Selling the Value

Another key reason why PMOs continue to get a bad rap relates to the PMO not “selling itself”. The solution an organization decides to build must clearly state to the customer/stakeholders, “What is in it for me?”  Here are some key metrics that senior management will be looking at when assessing the PMO value and engaging it across the organization:

• Controls over the financials – baseline ‘before’ and ‘after’
• Reduction in turnover by supporting project teams
• Greater project output (on schedule, time, budget)
• Flexibility to adapt to changing environment (how we handle change)
• Regulatory/Compliance (i.e. SOX) – controls over project investments
• Increased market share via reducing missed opportunities (decreased time to market)
• Stakeholder satisfaction
• Standardized way of doing things which infers increased productivity

Summary

Organizations continue to pour time, money and effort into building a PMO only for it to end up with a bad rap. Now is a good time to rethink how your PMO was built or how you are going to build one – and approach it using project management processes/practices!

*Contributor – Juliann Knott, Executive Change Consultant

Download PDF

Keep Poor Vendor Management from Impacting the Bottom Line

A recent public announcement by a local government disclosed that over $6 million had been spent on a program for the judicial and criminal justice systems, but that nothing had been delivered.  The program was ultimately cancelled.

In the fourth quarter of 2005, a publicly traded company announced to their shareholders and the public that the last quarter dividends would be reduced $.30 – $.40 per share due to “problems” with the poor execution and deployment of a new Enterprise Resource Planning system (ERP).

The bottom line in both of these real-world examples is that the organization, its taxpayers and shareholders were negatively impacted by the misspending of project funds.  These two examples demonstrate significant investments that required managing an outside software vendor.  Many companies will turn these types of initiatives over to the vendor only for the project to falter or fail.

Who is to Blame?

In today’s world, when something goes wrong everyone likes to put the blame on someone or something.  These examples are no different.  People often blame problems on one specific area, such as technology, poor vendor management, an organization’s ability (or inability) to change, the management/leadership and the list goes on.  I believe that the root cause of these problems is poor execution of program/project management – of which vendor management is one component.

The more mature organizations are executing projects using defined success measurements, business-based governance and oversight of these dollar investments, embracing change improvements and doing the “right” projects the right way.

When a change initiative is large, in terms of overall investment and business impact, it does not make sense to turn the organization’s success over to a vendor with conflicting priorities.  The vendor goes away at the end of the engagement, but the organization must live with results, good or bad.  This has led me to believe that organizations should consider the use of an unbiased, certified project management professional (PMP) to oversee the client and vendor performance to ensure success.

Execution Risk

There are many risks associated with major initiatives that involve an outside vendor.  One example is every time you hand off a responsibility, you are incurring inherent risk. This holds true for all instances including when a software integrator or consulting firm is engaged and even when you ask for support from your own team members.  Execution risk becomes significantly more when there are large dollar investments, software integration, changes in enterprise business processes and associated and expected employee and/or customer behaviors.

Leadership Risk

Another risk is when an operational manager with other responsibilities is brought on to oversee a visible and business transformation initiative.  Our profession terms this the “accidental” project manager.  The accidental project manager is generally someone that does not possess the skills or the experience to drive a large change initiative (program or project). They are most adept at running the business as usual environments vs. dynamically changing project world.

Those that come out of the operational (business as usual) environments that have been successful in transitioning to a new and different role can attest to the differences in required skills and aptitude.  The following example shows what can happen to projects led by accidental project managers who are not trained to manage large initiatives involving outside vendors.

A government agency was installing a significant ERP where the vendor was chosen via bid process.  The accidental project manager recognized at a very late date that the vendor was incompetent and not performing.  The vendor was subsequently dismissed and then proceeded to take the government agency to court.  Because the contract and vendor performance had not been managed, tracked and clearly documented, the vendor left with an additional $3 million in their pocket for non-performance of the contract.

It is also important to remember that when vendors and contracts are not managed, the cost is not only to the organization, its shareholders or taxpayers as in the examples above, but the careers of project sponsors can also be negatively impacted.

The True Value

My experience in our industry has left me with invaluable insight from clients that demonstrate what they have gained from having an independent, certified PMP onboard to execute these types of projects.  One of the benefits is the creation of tangible documentation that not only ensures that the project has appropriate controls, transparency, use of disciplined processes to mitigate risk but essentially is completed on time and within budget. These controls and documentation can be leveraged in the event that legal issues surface.  Project sponsors and stakeholders do not want surprises regarding vendor communication of status, deliverables and releases.  Some other specific examples of documentation that outside, certified project managers can provide include:

• Fully integrated workplan that includes vendor and client deliverables and activities
• Clear Statement of Work for vendor activities – level setting expectations in writing
• Clear, reported metrics regarding Service Level Agreements – the are indicative of vendor performance
• Quantifiable metrics that represent current and future state associated costs – this measurement is called Earned Value – if the vendor has invoiced 70% of the contract and completed 10% of the work – there is a gap
• Formal processes for managing changes – those submitted to the vendor (these changes may represent management of cost, timelines, risks, quality and lastly, knowing if the change has impacted someone else)

According to my past clients, the value of an independent PMP is also demonstrated in their ability to ensure that the client’s infrastructure is in place to support the program/project governance, sponsorship/ownership and that the client methodologies are integrated with the vendor’s processes.  My clients also say that a qualified professional project manager can place equal focus on the business and technology transformation and integration.  Other areas in which such a resource can benefit an organization include:

• Ensuring that the vendor has appropriate processes in place to support quality requirements as well as a structured method for review and client acceptance of deliverables, release control, incident tracking and revalidation
• Managing vendor and client contracts and performance as well as collaborating with client procurement/sourcing partners for contract questions/performance indicatorsEnsuring there is performing vendor software in escrow that has been accepted by the client and outlined in contracts
• Transition of vendor knowledge to client resources prior to vendor exit.

The Bottom Line

Executing an initiative that requires an outside vendor does impact your organization’s bottom line.  Allowing the vendor to oversee the project or designating an accidental project manager can have serious consequences to your organization.  You should be aware of your options, consider your risks and identify insurance for success for you and your organization.  Consider the value of an independent, experienced project management professional (PMP) to oversee your next initiative that involves vendor management.

*Contributor – Karen McIsaac, Managing Director

Download PDF

Definition of Insanity: Doing the same thing over and over and expecting a different result

Do you do the same thing over and over again because it’s comfortable, no matter the outcome? In our unique economic environment, complacency equals inflation, inflated project costs that is.

Now, more than ever, is the time to consider how to plan, execute and control projects to avoid the excessive cost and schedule overruns experienced and accepted in the past. In order to do so, you have to deviate from your comfort zone.

Today is the day to become creative and make a concerted effort to evaluate project options based on requirements and weighted evaluation criteria and select the approach that is right for your company, customers and shareholders.

What are the options and how do you choose?

Regarding project options, it isn’t like Baskin Robbins where there are 31 flavors to choose from, in fact, just two. DIY or buy. Either can be customized, but ultimately you complete the project internally or outsource all or part to an external vendor.

Chances are you are more confident executing one option or the other; however, if you do the same thing over and over again, you will get the same result. For most companies, their project track record could use some renovation and innovation especially NOW.

Do It Yourself (DIY)

Completing the project in-house is often preferred but seldom selected given the fear of responsibility and accountability for meeting project objectives, especially where failure comes at a high cost. With budgets tight and jobs at stake, fear is no longer an option.

As a guideline, it is better to complete the project internally if the following apply:

• Excess resources are available (materials, personnel)
• Required skills are found in-house, easily acquired externally or training is readily available
• Control/authority is a key driver within the organization or project
• Ownership of quality, cost and schedule management is critical
• Project or process is proprietary or confidential

Keep in mind, you must know what it takes to “keep the doors open” (personnel, materials, spend) before you allocate discretionary resources to projects or programs.

A recommended variation of the “do it yourself” option is to build out and enhance your internal team through an external company that can provide experts to augment your staff, which ultimately leads to the following benefits:

• Cost savings – you pay only for the resources needed
• Streamlined communications – roles and responsibilities are clear and not duplicated
• Increased control and risk mitigation
• Opportunity to transfer or retain knowledge
• Oversight outside of a formal contract  - within a Statement of Work (SOW)
• Time/cost savings of contract bidding (RFP’s, etc.) and negotiations
• Schedule ownership – the organization dictates and manages the schedule versus the vendor

Buy

How many times have you heard, “you have to be in it to win it”, meaning if you are watching from the sidelines, you have no chance at all to be successful. The same applies here. If you hand your project over to a third party, you are placing the fate of your project, and possibly your career, in their hands. With due diligence, clear contractual commitments and an SOW, outsourcing can be a positive experience.

 Buying versus completing the project in-house can provide several benefits as external vendors can often cut through political environments, provide independent oversight, incorporate best practices from previous engagements and with adequate contract terms, share or mitigate project risks. As long as the key risks associated with outsourcing are mitigated, this option can be extremely valuable under the following conditions:

• Expertise is not available in-house and cannot be readily acquired
• Cost to purchase and maintain is less than the cost to develop and maintain internally
• Product has already been developed, tested and implemented successfully elsewhere and can be integrated with little change

Exposure or Windfall?

There is no silver bullet with one option or the other, and each is not without challenges and opportunities as outlined below.

Cost

If you choose to complete the project within, there are usually lower internal hourly rates, limited incremental management overhead and nominal travel expenses as costs tend to be reduced and more predictable for in-house projects. If you outsource, you may also be able to capitalize on fixed bid contracts with an external vendor as long as the project requirements are comprehensive and changes minimized. ROI and project risk should influence the approach selected and if needed, contract type and terms.

Timeline

How frequently are “canned” timelines presented by external vendors and guaranteed to work in every environment? Unfortunately this occurs all too often, resulting in quality concerns, cut corners, more money and missed deadlines without notice or penalties. However, in-house projects are not without timeline risk, especially if the project is unique, resources are focused on both operational and project work or there is no sense of urgency. An integrated workplan, measurement and performance criteria, continual risk assessments, formal tollgates and controls are essential to attain project success for either option.

Control

Internally, the focus is typically on “doing the right thing” for the customer.  You are closer to the actual work with greater flexibility to change if necessary.  For good or bad, with outsourcing, when you sign a contract with an outside vendor you are “locked in”, and the terms agreed to upfront are the rules to live by.  Consider the number of anticipated changes, need for flexibility or agility and level of scope definition when weighing options and negotiating contracts.

Quality

Utilizing a vendor is often seen as an insurance policy for program success.  Historically however, most buyers have performance, quality and/or expectation issues after selection and contract signing, which may not be known until later in the project. Take caution, as your expected level of quality, or acceptable quality protocols for internal projects, may not be built into the vendor timeline or price and must be spelled out in the contract or SOW.

Resources

Dedicated (full or part-time) internal qualified project resources are hard to come by, especially now with increased layoffs and reduced hiring, but once secured, team cohesion, collocation, oversight and motivation are often easier with in-house projects. It is much more difficult to lead and manage external resources (they are generally ‘directing’ you), especially if they are offsite or offshore, traveling each week or transitioning on and off the project. However, many of the resource risks can be mitigated with independent project oversight and comprehensive communication planning and management.

Summary

Whether you make the decision to do it yourself (DIY) or outsource your project needs, each approach is not without risk. With the proper identification, planning and mitigation, the pitfalls that normally derail projects can be mitigated and opportunities exploited. Now is the time to think outside the box and truly examine your options. Remember, if you do what you’ve always done, you’re going to get what you’ve always gotten.

*Contributor – Gail Bennett, Executive Change Consultant

Download PDF

Accounting for Misaligned Political Agendas

Most experienced project managers are versed in how to technically initiate, plan, control, execute and close a program/project.  However, having these skills can result in being very process driven, which in turn means that project managers can miss the “culture” issues associated with mission-critical, cross-functional initiatives.  These issues, organizational nuances and misaligned political agendas represent significant project risk that is not easily identifiable through standard risk assessments.

What is a misaligned political agenda? 

No one likes to use the term ‘political,’ but let’s face it, that’s the term everyone uses when dealing with a cross-functional program/project that involves many stakeholders from all areas of the organization.

Anyone associated with project management understands that there are many tools and methodologies available that can help to ensure that an initiative is delivered on time and within budget. Unfortunately, those tools alone will not ensure that all stakeholder needs, expectations and support are aligned.  This is something that project managers must learn to recognize and mitigate so that their project can be successful.  Perhaps one of the best ways to illustrate a misaligned political agenda is to share an example.

In this situation, the initiative had already experienced two starts, was unsuccessful to date and was about to start a third time.  The project was critical to the client as the current environment was causing significant customer issues which resulted in significant backroom operational issues, including additional costs as well as customer frustration.

A new project manager was assigned.  She had delivered a similar solution in the past, so this project was not to be overly taxing or challenging as an initiative sometimes can.  However, the project manager had no experience with the client organization and culture. The project was cross-functional in nature as it was dependent on the support and engagement of approximately twelve unique areas of operation. The issue was that not all of those stakeholders shared the perspective of the importance of this project.

So what happened during project execution?  First, the executive sponsor driving the project was not adept at garnering up-front support of the cross-functional partners/participants.  Second, the project manager did not consider all of the stakeholder agendas.  The stakeholders were not fully engaged or supportive, which resulted in several additional stops and starts and unnecessary delays.  Though the project plan was being managed and the communications prompt and clear, the project was not progressing at the pace dictated by the plan.

Why?  There were several different political agendas being executed. If the project sponsor does not (or will not) align them, it is the project manager who must align and engage those that are negatively impacting the project progress in a diplomatic (non-political, unbiased and impartial) manner.  In this specific scenario, the project manager had to revisit, realign, engage and coach all of the cross-functional managers.

When the project sponsor and all of the stakeholders became engaged and supportive, the project picked up momentum and the underlying tension was eliminated.  Until that point the unseen political risk was jeopardizing project progress and success.  The project manager in this example learned that to be successful one must serve as the diplomat that pulls everyone with varying agendas to the table for open discussion.

Steps you can take

In all projects, the best way to prevent misaligned agendas is at the inception of the initiative.  At that time, there are several areas where the project manager can take steps to potentially prevent issues down the line.

One of the first steps that you should take is to identify and include every stakeholder as a part of an oversight committee, sometimes referred to as a governance committee, which serves to bring everyone together.  This infers that every cross-functional area has been identified from an impact/ownership perspective and included because exclusion can have detrimental effects on the project.

The next step is to talk with the stakeholders to find out what is critical for success to them as well as their commitment to the effort.  Are they committed to the project or there in name only?  Be sure to integrate all stakeholders’ perspectives for tracking purposes and continual review.  You may need to meet with each key stakeholder independently to ensure candor during the conversation

After speaking with stakeholders, you should create a communications plan that will help establish standard meeting routines and ensure clear and frequent stakeholder communication.  This will manage expectations and minimize surprises as well as garner continued dialog among stakeholders.

All of these steps will lead to a commitment of project resources from each stakeholder that is responsible for representing their interests.  Keep in mind that a lack of human capital commitment will prevent the project from progressing as planned.

As with every project, there are issues of “time constraints” of cross-functional participants due to other commitments.  To prevent any surprises in an oversight committee meeting, be factual about reporting them one-on-one to the stakeholder responsible for the cross-functional area and the associated impacts on the project.  Time constraints are real and you should look for any options that may support resolution of the issue.  No one wants to be reminded that they provided the “wrong” human resource.

During project kickoff you should ensure that all representatives from the cross-functional areas are included in risk identification, areas of impact, the work breakdown structure for project plan development, identification of what’s critical to quality, their respective roles/responsibilities and all expectations (“the rules” of engagement).  Keep in mind, exclusion promotes non-ownership.

Remember, the project sponsor should be the person responsible for aligning political agendas and garnering support.  Whether this is actually the case or not, you must ensure that the project sponsor is apprised of all issues, political situations, support/non-support of participants of dependent/impacted cross-functional areas and overall project progress (budget, milestones, deliverables, change controls) on a regular basis and prior to any stakeholder meetings.  Your job as a project manager is to ensure that the sponsoring executive is successful along with the project.

Most project teams comprise a mired of team members that represent a matrix managed group.  In order for the project to run smoothly and for the group to be successful, each of your team members should have a method of communicating with their management.  By assisting in this process you have the opportunity to influence how the communication is delivered.  It’s also another method of core team and cross-functional team member support as well as ensuring the appropriate communication of facts vs. assumptions.

Your project team’s lack of experience can be detrimental to a project.  You should address situations where the cross-functional and/or core team members may need additional training and support by communicating these needs to the sponsor and appropriate stakeholder.  It’s usually best to offer options rather than removing the person from the project.

Though most project managers may possess the technical skills of initiating, planning, executing, controlling and closing a project the “soft skills” are just as important.  Projects are about people, people working together to achieve a shared goal – note, shared goal is most important.  The project manager is a key element in ensuring there is a shared goal among stakeholders, core and cross-functional team members. Everyone’s perspectives, experiences, skills, priorities and “end game” are important and to be respected.  Your challenge is aligning them to the goals of the project.  As a project manager, possessing the following soft skills will potentially prevent misaligned political agendas:

• Remain an unbiased execution lead. As a project manager, remaining unbiased minimizes any promotion of political agendas on your part.
• Clearly represent facts and communicate them to the stakeholders and solicit feedback.  Attempt to deal only with facts and not assumptions.  Issues don’t belong to one area; they are shared among the stakeholders.
• Recognize that every cross-functional area impacted by the project represents additional project risk, from a political, resource and change perspective.

Summary

Though projects support an organization’s goals, objectives and targets, they are also a forum for political havoc.  Everyone has unique goals, perspectives and opportunities as is evident within every project team as well as at the executive and sponsorship levels.

The misalignment of political agendas can sabotage a project when there is no “apparent” reason for its lack luster success or failure.  Early recognition of the politics surrounding a project initiative and taking action can help garner support from all areas, including the team and project sponsor.

As in any team sport – the team wins, the coach loses.  Don’t be the losing coach!

*Contributor – Karen McIsaac, Managing Director

Download PDF

Projects Represent Risky Business

Any major change or project represents some level of risk. Does this mean that all organizations properly assess and manage risk during such change? Not according to this scenario.

Shares of Invacare Corp. fell 5.8% to $31.50 after the Ohio-based company said it expects its performance for the fourth quarter to come in below prior expectations due to problems with the implementation of a new enterprise resource planning system. The company estimates the resulting temporary disruption of order processing capabilities and inefficiencies caused a revenue shortfall of about $30 million.[1]

Outcomes like Invacare’s are often attributed to poor Risk Management. Consequently, without a Risk Management plan, you, the project sponsor and the company are in danger of such failure. Failure could mean cost and schedule overruns, project termination and shareholder backlash.

If you do not want to face such potential problems, you should have a Risk Management plan that considers all potential risks, how they will be dealt with and by whom.

 Risk Management Defined

According to the Project Management Institute and its Project Management Body of Knowledge (PMBOK®) Guide, Risk Management is considered a systematic and proactive approach to taking control of projects and decreasing uncertainties. It involves minimizing the consequences of adverse events while maximizing the results of positive events. Risks can be good (opportunities) or bad events (like the scenario above).

Risk Management is also an iterative process, not a one time event, within each lifecycle phase of a project. The Risk Management plan should be revisited as changes are always occurring and more information is discovered. As the project progresses, the plan should become more fine-tuned.

Risks vs. Issues

Before you can successfully identify and mitigate risks, it is important to understand what is considered a risk and what is not. The most common mistake is confusing “issues” as “risks”. Issues are dealt with throughout a project and are not addressed in the Risk Management plan.  It is important to understand the difference between the two.

An issue is a problem that can be resolved. Depending on severity, issues can stop, delay, change direction and increase the cost of a project. If you were implementing a new HR/Payroll system and did not know the latest IRS rules concerning 401K contributions that is an issue. As the project manager, you would identify the resources needed to research, validate and document these rules within a specific timeframe to keep the project on schedule. Issues are generally reviewed and addressed within every project team meeting; new ones come to the forefront, existing ones’ status for resolution is reported.

On the other hand, a risk is a potential future event or occurrence that can have a positive and/or negative effect on a project or organization. Risks are mitigated or assumed prior to occurrence and generally do not stop a project. For instance, the new HR/Payroll system you are implementing may incorrectly calculate the 401K contributions for employees after the system has been installed. This is a predictable occurrence and should be mitigated before the actual installation, which is where Risk Management comes into the picture. Within each phase of the development life cycle, risk needs to be reassessed as progress is made and new discoveries occur.

Basic Steps in Risk Management Planning

Now that we have defined risk, it is time to look at the five basic steps to begin your mitigation strategy:

1. Plan
2. Identify
3. Quantify and Qualify
4. Respond
5. Monitor and Control

So at what point in a project should you begin? The sooner the better!

As you begin defining the project charter and scope, leverage the project sponsor and others to help start identifying risks, even though you may or may not have a team assembled.

There are many sophisticated and automated tools that can help the project team and project partners in planning for risk, including Syntex® and Logic Manager®. There are also simple methods (such as the charts to follow) that may help your planning process.

Considerations for Risk Management

When beginning a project, a project manager often starts thinking strictly in terms of schedule, budget and quality risk. However, these risks, although important, only represent a partial picture of your Risk Assessment. Other risks that should be considered include:

• Vendor
• Operations
• Media
• Reputation
• Career (yours, your sponsor and your team)
• Customer
• Shareholder (sited above)
• Interest Rate/Market
• Legal
• Compliance (SEC, etc)

Initially gathering together the right people who can think of every possible future risk scenario (good and bad) is critical. Depending on the size, complexity, impact and scope of a project, the participants may include those outside of the core project team. For instance, consider reaching out to the marketing department to help identify and mitigate media and reputation risks. What matters most is that you utilize the right people needed to uncover ALL potential risks.

You may be asking yourself if these risks are really ever “realized.” In another recent news story, a financial services provider experienced technology and customer servicing problems due to a major cross-functional change initiative. Customers did not have access to their invested and deposited funds for over one month, according to the story. In this instance alone, there was significant impact in the following areas: customer, operations and media. The overall reputation of this stoic organization was also jeopardized.

By not considering all types of risk, you could be setting yourself and the organization up for major problems down the road. As the project manager, it is your responsibility to ensure that all risks are identified, mitigated and/or assumed by the project sponsor.

Define Risk Levels

As you and your team consider the various types of risk, you should also consider the threat level that each one presents. The chart below includes the simple definitions of the various risk levels. This is intended to be an example only, as you and your team should review the definitions of risk levels utilized by your organization.

High	Most likely to occur	Almost certainly will cause significant disruption to the project or the business resulting in the need for specific controls and contingencies.
Medium	May or may not occur	Likely to cause delays or additional work resulting in additional time, resources and workarounds.
Low	Not likely, but not impossible	May cause delays or additional work that could be contained within existing contingencies.

Identifying Risk Impact and Probability

The chart below is another example of how to rank the levels of risk and determine which need to be considered first. To use the chart, first you will need to consider the impact and probability of each risk. The chart then allows you to determine those with the highest risk and ultimately which should receive top priority.

The left hand side of the chart represents the level of impact and the bottom represents the likelihood that the risk will occur. For instance, if the impact and probability of a risk is high, then that represents a maximum risk and should receive top priority.(Click graph to view)

As you and your team look at each risk, consider the following:

• What could go wrong
• What is the probability of it going wrong
• How significant is it if it goes wrong
• Who is responsible for what when it goes wrong
• How can we mitigate or prevent it from going wrong

Conclusion

Projects represent risky business, but that doesn’t mean you can’t be successful. While this white paper provides an overview of Risk Management, you should continue to educate yourself on the subject especially around the practices of your particular organization. Ensure that your next project has a Risk Management plan and that it is revisited at every lifecycle closure and engage everyone associated with the project in planning for risks. Follow these steps and rest assured you won’t be reading about your failed project in the news!

*Contributor – Karen McIsaac, Managing Director

---

[1] MarketWatch – December 14, 2005

Download PDF

Taking a Good Team and Making It Great

As project managers, we are generally provided the opportunity and the complete responsibility for delivery of a project. We often do not have input in the selection of our team members, nor do we have any administrative authority over them. So, given this reality, how can we take a sometimes disparate, more often over allocated group and turn it into a highly self-motivated team?

Many projects represent challenges and learning experiences so team members are ready to dive in at the beginning. When team members become unfocused (the goal is not reinforced and secondary issues divert attention away from it), their drive for achieving milestones and attention to details begins to wane. Deliverables and quality of work begin to slide, which causes rework, schedule and cost impacts, in addition to unwanted additional stress on the project manager!

Your role, as a leader, is to reinforce the project goals. Encouraging people to be their best sustains self-motivation of team members. Your expectations about quality need to be shared by the team members producing the products. The team’s overall goals should include not only getting the job done, but getting it done right the first time.

Everyone wants to have a team that exceeds expectations, freely points out issues and offers innovative and well thought out solutions over the course of the entire project. This is where the project manager plays a vital role. You, along with your team, should set your goals regarding expectations to ensure that no one on the team is a “passenger.” Setting these types of quality goals ensure a project team that offers options to solving problems.

Start Off Right

The project kickoff is one of the most important components of the entire project. The kickoff sets the stage; it should provide the team with a clear understanding of the initiative’s goals and objectives, their importance to the project AND how it supports the strategic business objectives of the organization.

The sponsor is a critical component of the kickoff meeting. If this individual is missing in action then the perception will naturally be “this is not very important.” Team morale can be quickly sabotaged at the initiation of the project. It is our responsibility, as project managers and team leaders to ensure that this does not happen. We occasionally have to coach the sponsor, not just our team members. The success of the sponsor is dependent on your success and your team’s success. Ensure they are fully engaged from project inception. This engagement must be visible throughout the life of the project because the sponsor is the person that has accountability for the results.

Keep the Momentum Going

Changes to the project team are inevitable. Some move off the project and some are added, but we generally do not think about helping the new person get acclimated to the routines, expectations and goals or even the project’s nomenclature.

When new team members are brought on board, it is our job to help them ramp up quickly. This helps them feel like contributors, keeps the project momentum going and builds a speedy integration into the project team. Have you thought about having a small orientation package for new team members? We are generally so focused on our projects that we lose sight of the reality of new team members.

There are many sources for orientation packages, from kickoff meeting materials to a glossary of the project nomenclature. One of the best sources in terms of “orientation” is you…no one should know more about the project than you! Spend time supporting new team members; they are “jumping in” where someone else may have left off. Remember, your success depends on them being successful and you can foster their success by meeting with them individually. This level of support generally leads to trust, which is an essential ingredient to open communication.

Know Your Team

I’ve always said that projects are about people. They may deliver results (products, services, witjits, etc.), but there is no delivery without the people. Knowing your team becomes one of your assets!

Your project team most likely consists of people with very different backgrounds, personalities and motivations. A junior analyst on your team may want to become a better analyst or the next great project manager, but the business partner may be trying to save his career. As your project ramps up, you should begin to develop relationships with your team and uncover what motivates them by asking, “What’s in it for you?” If you genuinely show an interest in getting to know your team, and in helping them reach their goals, they will be much more likely to act in a way that benefits you, the team and the project.

Everyone has unique motivations, unique ways of working and unique sets of issues. When someone asks, “I wonder what’s wrong with him/her,” you should find out. This is not a time to be nosey; this is a time to be supportive. We have all been on stressful projects where a team member may be going through challenging personal issues. Do not assume that someone is not being “cooperative.” Give them the opportunity to succeed with support.

Another aspect of knowing your team is to understand how they work best. Some people prefer to work in areas where they are the recognized “subject matter experts.” Others want to work on the innovative, “fun stuff.” Some people like things to be “black and white,” others are more comfortable with turning the gray to black and white. Keep in mind, even though project managers and team members are all about driving change via our various projects, most people do not embrace change!

Team Spirit

So, you’ve started developing relationships with your team members, how do you maintain a high level of interest, self-motivation and “team spirit” throughout the duration of the project? In my experience, all it takes is some simple recognition.

I was the Program Manager on an 18 month international initiative with a Fortune 500 client. One of the projects was moving forward as expected, however, there was a sense of resistance and negativity surrounding the team. It was obvious that I had to utilize my leadership to influence this resistance or the project would be significantly and negatively impacted. My solution? I started a monthly “Most Valuable Team Player Award” (MVTP) which got the results I needed as well as some pleasant surprises.

At the end of each month, I selected a team member that I believed had gone above and beyond the call of duty and acknowledged that person in the PMO status report that was distributed to the entire project team. I also presented the MVTP with a small pin. As project managers, we can influence our team members directly by these small recognitions, but also indirectly with input/feedback to their administrative managers when someone has “exceeded” expectations.

How did the MVTP award turn the negative attitudes around and get the team motivated?

It was an opportunity for the team members, including business partners, other project managers, team leads, technology partners and support staff to be recognized in front of their peers as well as senior leadership.

As with all competitions, once you start keeping score, the game changes. After the first MVTP award was given out, the business partners associated with the projects begin to engage in a friendly rivalry. Business partners and other team members began to increase participation and become fully engaged in the project and attitudes were much more positive. The entire project team became more motivated. Due to the competitive environment, quality and performance increased dramatically. What was intended to be a very lighthearted competition resulted in bringing the team closer, and we shared some great laughs. In the end, the difficult project milestones seemed to happen with less effort.

Through the MVTP award, I realized that acknowledging and empowering ancillary team members can have powerful results. These team members, though not part of the core team, are essential to project success and by developing a relationship with them, a win-win situation is produced. Not only do they feel appreciated and part of the team, they are willing to support you in your current and future project roles. One year after I moved on from this program, I continue to foster the relationships built with this simple recognition.

Communication + Connection = Cooperation 

In my experience, communicating and connecting with people solidifies relationships and fosters support and cooperation. Being “in touch” with your team cultivates the good team into becoming a great team. Remember, projects are about people! Your people skills will build the personal connections that last long after the project has ended.

Download PDF

Only One Goal Can Be #1

We’re all familiar with projects that keep piling on functionality or gold plating features, but scope creep becomes irrelevant if no one really knows how the project is aligned to the company’s overall strategy. In addition to well-formed boundaries or scope, a project needs a clearly defined primary driver. The project team may define success differently than the sponsor or business, and everyone working on a project should share the same goal. Only one goal can be #1.

What’s the Driver?

Let me give you an example.

A recent client initiative was chartered with meeting a very specific timeline, which meant deploying the new solution in the next quarter. The project team was experienced and could execute in the given time frame if they could rely on existing skill sets and technologies already in place.

However, it was not uncommon in this organization for in-flight projects to lose valuable time well into the project, not strictly because of scope changes, but because of management indecision about strategy and prioritization on project drivers.

Not long into the initiative, the project team was sitting in yet another uncomfortable status meeting, and management was asking why the solution wasn’t aligned with the organization’s evolving technology strategy.

Initially, several stakeholders proposed the new strategic platform, but in addition to new hardware and software the solution would require resources with experience or expertise in the target environment. There were no corporate plans in place to hire additional staff or allocate funding for training current staff. Duration and budget estimates for this approach were too high, so the project sponsor requested a more aggressive timeline and a much more modest budget.

Both options provide the company with a solution, but the solutions aligned with different strategies, solved different problems, contained different risks, and provided different value to the company.  Projects at this organization didn’t know what corner they were in.

The primary driver for this project, it had seemed, was to meet the date for implementing the solution – and now that could change. If time (and cost) were the primary drivers, it made more sense to utilize existing infrastructure and leverage the skill level of the project team. The project could be implemented quickly and with available skill sets. However, the fastest, cheapest solution might also be dependent on end-of-life technology and obsolete by the time it was implemented. The project could be delivered on time and on budget, but who wants a solution that doesn’t deliver value to the business?

Scope was only indirectly the challenge this project was facing. The problem had more to do with alignment of the project to the company’s strategic goals.  And as obvious as it sounds, only one goal can be #1.

While the stakeholders and managers appeared to have agreed on the project charter and requirements, they had failed to agree on the primary driver for the project. Was it cost, scope or time?

 The Triple Constraint

In project management, all projects are bound by the constraints of cost, scope and time, or the Triple Constraint, which was also causing the confusion on the initiative mentioned above. These three drivers are also referred to as the Project Management Triangle, where each side represents a constraint and one side of the triangle cannot be changed without impacting the others.

Awareness of the triple constraint:

• Helps evaluate competing project demands
• Focuses effort to the most important priority
• Ensures everyone working on a project shares the same goals

According to the Project Management Body of Knowledge (PMBOK), project managers are responsible for balancing the competing demands for quality, scope, time and cost or anything that limits a project’s options. Project managers have the responsibility to provide the sponsor with information on all corners of the Triple Constraint and how they contribute to the project success.

It is the project sponsor’s responsibility to actively accept the trade-offs resulting from a priority shift from one “corner” of the triangle to another. They represent what the organization values and must also accept the resulting risk to the project when priorities change.

The Triple Constraint defines the success driver of the project and directly or indirectly, management determines the priority of the success driver.

Indirect prioritization, as in the example above, created a moving target: project decisions were first driven by the timeline, then by the budget, then by the awareness that the end result had no strategic value. When the Triple Constraint is fluid it creates delays and projects end up being driven by circumstances instead of by strategy. It is inevitable that events or priorities will shift and impact in-flight projects, but a clearly communicated and agreed-to project driver can keep a project on track.

Cost, Scope and Time as Primary Drivers

The triangle of cost, scope and time must all work together and be balanced with project risk and the quality of the expected results of the project. As I mentioned above, a change in cost, scope or time necessarily impacts the other two. In addition, changes to the Triple Constraint will impact the risk of delivering the project as expected and the quality of the product the project is slated to deliver. Let’s take a closer look at the three primary drivers and their impacts.

Cost refers to the project budget and includes labor or effort as well as items which would need to be purchased to complete the project. Projects and project resources are not free. Costs spent on a project should be looked at as investments which deliver a business relevant outcome that positively impacts:

• Company resources and technology
• Making business competitive
• Improving company performance and operating results
• Ability to deliver product
• Strategic benefits

Budgets are always limited, so prioritization of scope and time to focus effort on the most important priority becomes critical to managing costs. People and dollar resources are most effective when allocated to what is highest priority. If project teams don’t know what’s most important from a strategic standpoint, they will have to decide which work is priority.

Scope includes the product features and functionality. It is integrated with quality and risk. Scope boils down to what the sponsor wants to buy for the price of the project. If scope is the priority, generally it will take longer and cost more. If budget or schedule is cut, risk goes up and quality suffers.

Scope items should be linked to strategic initiatives. Since a project provides something the business needs and is willing to pay for, they should pick what’s important for the project’s success. Approval of project scope drivers should involve trade-offs between budgets and duration or cost and timeline.

Time constraints include the desired project schedule, dependencies on other projects or project resources, and external events such as regulatory deadlines.

If everyone understands that the deadline is the main priority, like getting a marketing plan executed before a certain event – complete the ad before the Super Bowl – then it is much easier to manage. If a competing priority from another project or potential scope change comes along, no one questions it when you say, “We can’t do that AND meet our deadline. Deadlines come first. Sorry about that.”

But be careful, due date setting, without consideration for the other constraints, leads to high failure rate if they don’t account for:

• The effort required to do the work
• The availability of the team
• Dependencies to other  projects

Summary

According to the PMBOK, “high quality projects deliver the required product, service or result within scope, on time and within budget.” But truly successful projects provide much more than that. They provide business value and allocate project team members and company resources on what’s most important. Prioritization is determined by the project sponsor and not the project team. Actively managing the trade-offs required to best meet the project constraints of cost, scope and time make a project successful.

*Contributor – Currin Cooper, Managing Change Consultant

Download PDF

Turnaround a Faltering Project

If projects are part of your business, you know that many of them have the potential to fail.  According to one industry source, approximately 30 percent of projects fail. And of those completed, about 50 percent do not deliver the business value necessary to recoup their initial investment.  As the numbers suggest, it is not hard to fail…in fact project failure can be easy when both the cross-functional and relational risks are not identified and managed appropriately.

Many of the problems associated with project failure can be prevented, but in the event that a project begins to falter a disciplined approach must be followed to recover the initiative, forward your business objectives and ultimately your career (see graph on page 2).

Potential Failure Signs

The first step in turning around a project is to identify that the project is at risk. A failing project can typically be characterized by three factors:

• Missed deadlines
• Missed deliverables
• Cost overruns

In order to have a successful project turnaround, it is important to not only identify the signs of project failure, but to use those signs to offset the risks that can occur if action is not taken to get the project back on track.

Most failure signs can be categorized into three broad categories: politics, process and people.  A successful project turnaround for a Project Managers, Inc. (ProjectMgrs) client serves as a good example. Our client, a top 10 ranked financial institution, recognized in the first quarter that they had run out of capacity to print year-end customer statements due to acquisitions and organic growth. This posed several potential risks to our client, including customer risk – customers would lose trust in their bank, operational risk – customer call centers would be deluged with account inquiries and reputational risk – the public’s perception of the bank would falter. Consequently, the client initiated a project to implement significantly faster and more cost-effective print technology.

However, by August, the project sponsor noticed missed deliverables and year-end was quickly approaching. In short, their project was at risk of failing.

While not intended to be comprehensive, below is a list of some of the more common signs of a failing project along with some specific examples from our client’s situation.

Politics

• Unrealistic expectations of stakeholders, sponsors and/or the project team – Stakeholders, sponsors and the project team members were not coached on what the change meant to them so resistance was paramount.
• Disagreement over the length of the project schedule or the cost of the project.
• Vague Scope and Business requirements and/or design specifications, frequent changes allowed to evolve over time – No Steering/Governance group was created to ensure that changes/issues impeding progress were addressed.

Process

• Disagreement on scope or what changes had been approved – Documentation was non-existent therefore status and milestones were unable to be tracked and reported.
• Missed milestones.
• Closing out project phases without all of the deliverables having been completed.
• Deliverables deferred to future project phases.

People

• Empty chairs at project meetings – Roles and expectations of stakeholders were not identified so they did not attend meetings.
• Executive sponsor or other stakeholders not engaged – Stakeholders, roles and expectations were vague therefore they were not engaged.
• Project team is struggling, unfocused and/or mired down in trivial details.
• Project team putting in too many long hours

Assess

Once it is established that a project is in trouble the next step is to begin the turnaround process by assessing the failure points. This is the point where a firm like ProjectMgrs is brought in to manage the turnaround, or you continue this process yourself.

There is obviously a lot at stake and those issues need to be cared for, which means that identifying all cross-functional areas of the project is essential. When our firm is brought in we look for both the surface failure points, as well the hidden failure points.

The surface failure points are the easiest to identify, such as the lack of a clear project charter. However, identifying hidden failure points means finding the “relational” or political risks associated with large cross-functional initiatives. To identify these hidden risks, a quick but necessary individual dialogue needs to occur between the assessment team and the project stakeholders.

Political problems often take the form of active or passive resistance to the project from both the business side and the IT side. What is the basis for the resistance? The answer to this question, if not recognized and coached, can sabotage a project’s success. Without identifying a project’s hidden risks, even the best-managed project turnaround will still most likely fail due to misaligned stakeholder agendas.

In our client’s case, the technical support areas at the client site posed a “relational” risk because they were apprehensive about the new print technology, as they would have to learn how to support the new hardware/software. Identifying their apprehension was critical to the project’s successful turnaround because they played a key role in the deployment of the new print technology and processes and also to the ongoing support of it.

ProjectMgrs was able to get the technical support team fully engaged in all project activities and sent off to training prior to beginning any testing of client print jobs within two weeks after the vendor installation of the hardware/software.

This particular project turnaround did not allow extensive time for studying or reviving prior missteps, which is often the case.  Remember, if a project is failing that usually means that precious time has already been lost so a quick but thorough assessment is best.

Restructure

The primary objective of the restructuring phase is to mitigate the failure points – surface and hidden – that are revealed in the assessment phase.  Once these failure points are identified and the assessment is complete, a meeting should be scheduled with the primary project sponsor to review the restructuring strategy to move forward and ensure that key objectives are met.

All too frequently project failure is blamed on technical issues. But in fact this is usually a symptom rather than the root cause of the problem.  Time is better spent on restructuring the project based on the failures of the project. Restructuring efforts should be focused around short-term, measurable goals that address the project’s failures.

A successful restructuring strategy will ensure that the project turnaround begins in a way that collectively gains momentum to hit key objectives. Because projects are usually midstream when the failure is identified, the restructuring strategy may require some prioritization of deliverables, resources, etc. to meet original targets in now compressed timeframes.

The restructuring strategy should include only those aspects of a standard project methodology required to ensure success. Unproductive project steps should be eliminated. The strategy should also include a quick status “dashboard” for project sponsor updates moving forward.

To eliminate unproductive process and steps in the turnaround, identify the original project charter (if it exists), any scope and requirements documents and utilize the components, if any that are working. For instance, is the communication process working? Are testing efforts producing good results? Are end-users appropriately engaged in the project? Is the coordination between the technical team and the business team working properly?

The first step in restructuring our client’s project was to complete a project charter/scope document to ensure that everyone involved understood the project objectives and what was “in” as well as “out” of scope.  This was leveraged to gain consensus with the newly formed Steering Committee and was completed in five business days.

In the restructuring phase, it usually isn’t necessary to discard everyone connected with the project and start over from scratch; in fact ProjectMgrs discourages it. Our goal is to get your project turned around or implemented with a clear transition to your team.

Understandably, most project managers would love to be able to staff their project team with the absolute best resources available.  Unfortunately, the best resources are usually in high demand within any company, and rarely available. Therefore it is up to the project manager to get the best from every team member.

It is during the restructuring phase that ProjectMgrs develops a “knowledge” transition strategy into the statement of work so that our clients become self-sufficient and not dependant on our firm or consultants after the turnaround is complete.

Restart

The primary objective of the restart phase is to develop a project workplan to implement the restructuring strategy. Key restart components may include addressing the “relational” or political risks that were identified during the assessment phase.  The project restart may also require project sponsor/executive participation to align previously misaligned cross-functional agendas of the stakeholders.

As part of the success of our client’s project turnaround we were able to execute a quick, formalized process to restart the project. We began by engaging the appropriate stakeholders that would “own” the resulting product, service and contract. Our client originally chose their new vendor via a very informal process. In order to streamline the process, we issued a letter of intent to engage the vendor prior to final contract signing. This fostered the delivery of the new print equipment, associated software and special rolls of paper to the client site within three weeks of our team leading the project.

Your project’s restart should begin at a logical starting point that follows a proven project management methodology. Proceed in small, incremental steps that should be defined in the restructured workplan or scope in order to reduce risk and show success faster. Throughout the project, make the schedule and status very visible in order to ensure a common and accurate understanding.

Execute

ProjectMgrs recommends that the implementation of the restructured workplan be executed by the same project manager (consultant or internal) that participates in the assessment, restructuring and restart phases. This individual should have the political clout and past proven success to meet your previous objectives with your new project strategy.

Optimize

After the project is implemented and success is achieved, you should have a postmortem process that will address the project’s failure points – surface and hidden – by updating or modifying your company’s program/project processes or education to ensure similar failures do not occur in the future.

For example, as part of our firm’s services, we offer a complete program office analysis to assess the maturity of your organizational internal project management processes. We identify the gaps, potential risks and financial impacts and make recommendations to improve your program processes. These recommendations will enhance your organization’s ability to execute projects well and achieve their intended financial benefits.

Summary

No one wants to be held accountable for or associated with a failing or failed project. However, as the statistics show, failures do happen and everyone should understand the steps that need to be taken when a project starts to fail. By following the six-step project turnaround methodology we have discussed, you can avoid the potential risks that accompany a project failure.

Our client’s year-end printing project was failing when ProjectMgrs was brought onboard in August. The actual year-end print was completed one week ahead of the prior year’s schedule, which had a positive impact on both the client’s customers and the print operations team.

The executive responsible for this aspect of operations was recognized as a leader by all other geographically distributed print operations sites – and eventually, they too, converted to the new print technology with his leadership.

As our example shows, there is no reason that a failing project cannot be turned around into a successful initiative as long as a disciplined approach is taken.

*Contributor – Karen McIsaac, Managing Director

Download PDF

You can’t manage a project without managing people

Project managers are often given complete responsibility for an initiative, but no real authority over the team members doing the work.  For critical initiatives that cannot fail, the project is all about influencing the people to get the work done.  Have you experienced one of the following scenarios?

A subject matter expert was just “volunteered” to be on your project.  However, she is already working 50 hours a week.

One of your project team members is retiring in three months.  She will be gone before the project is complete and is not committed her work.

The “A” player is not available so you are assigned the lesser-skilled “C” player to fill the “void”. 

In a perfect world, project managers could simply choose a team that “rocks,” but as matrix managers we must utilize the team members we are given.  So how can a project manager with no real authority lead a successful project?  We must use our influence and leadership skills to motivate team members to act in the best interest of the project’s goals.

Experienced vs. Exceptional

Most experienced project managers have acquired the ability to effectively lead the project initiation, planning, execution, control and close of an initiative – the logistical portion of project management.  Exceptional project managers have fine tuned the “people” side of project management.  They have the ability to use their people skills in three areas: managing the project team, interfacing with the client (or user) and interfacing with the rest of the company’s organizations.

The following traits are critical in a project manager’s ability to influence the behavior of the three areas above:

• Organizational and interpersonal astuteness
• Ability to compromise
• High level of self-control
• Team builder
• Commitment to team member development
• Strong ability to change communication style based on individual need
• Ability to interface with the client/user

The scenarios below represent common situations that project managers are likely to face during their career. Each scenario gives real examples of how I used the above traits as a project manager to influence the people on my team that were ultimately going to make or break my project.

Rally the troops

On cross-functional initiatives, project teams are usually made up of people that do not typically work together on a daily basis and may not even know each other.  They may feel that they are simply thrown together and expected to get down to business and start producing.  This inevitably can lead to team member conflict and miscommunication.

I had this challenge on a very high visibility project.  A core team worked to define, cost and gain approval for the idea and they felt a very strong sense of ownership.  Once approved, I was assigned to manage the initiative and the team was expanded to take the project through implementation.

The new requirements team lead that was brought on board was initially viewed by the original core team as an outsider that could not possibly grasp the detailed knowledge needed in the necessary short timeframe.  This created conflict and distrust among the team at large.  I had to gain a deeper understanding of the specific concerns of the core team, and fast.  Having been in a similar situation before, I quickly began to do the following:

• Scheduled a one-on-one meeting with each core team member
• Listened to their concerns and identified potential roadblocks
• Uncovered the core team’s recommended solutions
• Gained buy-in to the new team roles in a way that supported their solution and the overarching objectives of the project

By talking to the individuals that made up the core team and having them identify the roadblocks and possible solutions the requirements lead would encounter helped them move from a distrustful to a supportive position. Once you have this conversation, individual attitudes toward the project will help you drive the desired next steps.

The result was a cohesive team that focused on the necessary details and solutions needed for the project’s success, which resulted in respectful and trusting relationships.

This scenario shows how important it is for project managers to get their entire team on board by having one-on-one conversations to understand individual goals, concerns and solutions as it relates to the project objectives. Once this is done, you will have a broader understanding of what will motivate each team member and their career.  In the process you will uncover new solutions and even potential risks that you may not have gained in a group setting or team meetings.  Every team member has the opportunity to be successful, to learn from their project work and to be valued as a project team contributor.

The Non-Performer

A “non-performer” on a project team generally occurs in two situations:

1. She typically supports the best interests of her particular organization or department, but in the process may inhibit project progress.
2. She is over her work capacity and cannot commit the appropriate amount of time needed to complete the work.

In the first situation, you can leverage the commitment to help resolve the performance issue.  Approach your team member’s administrative supervisor and have a one-on-one conversation as in the previous example: mutually share concerns and discuss this roadblock.  Ask for the supervisor’s recommendations on modifying the team member’s actions to aid the interest of both the department AND the project.  It is always good to remind them of the importance of their representation via their team member.  You should also have your recommendations ready to present to the administrative supervisor, whether it is replacing the non-performer, asking the supervisor to address the individual directly or otherwise.

The second situation is very common.  In today’s world everyone is juggling more commitments than ever and some people may have more on their plate than others.  If you have a team member who is over capacity, you have a few options:

• Work with them to learn what tasks can be removed to create capacity required for the project.  Let them address the priorities and schedules.  Most importantly, you should always recognize them for their committed efforts.

• Identify someone to support them (if achievable).  This may be a less experienced person that can do some of the work with supervision and also be developed.

• Replace them.  Go to their administrative supervisor to share the capacity concern and have another resource with capacity assigned.

If you have a team member who does not agree with the pre-defined expectations of them and their role on the team or does not want to make the effort to meet these expectations, it is time to escalate and have a discussion with their administrative supervisor.  You should go into this conversation with facts regarding non-performance and the specific impact it is having, or will have, on the project and potentially the rest of the team.

Lack of Skills

You were assigned a team member that lacks the necessary skills required for the project and replacing the resource in this case is not an option.  This scenario is not necessarily the team member’s fault – it may be a condition/fact that the project manager has to accept.

To start, you should view this as a development opportunity for you and the team member, granted, it may be “under fire”.  You will be able to judge if the attitude and aptitude of the team member is contributing to making them more skilled and valuable to the team.

If the ‘developmental’ program is not working and your project is demonstrating the gap (budget and/or schedule are impacted due to this lack of project skills), your next step should be to address the issue with both the administrative supervisor and the project sponsor.  Remember, exceptional project managers know when to escalate!

Sponsor is Missing in Action

Have you ever managed a project where the business sponsor, your internal client, is nowhere to be found or is not a visible resource to the team?  Ultimately, the sponsor will be the recipient of the results of the project and they will be the ones measured on “success metrics,” as well as the project team, on the project delivery.  If it is not clear to the business sponsor that their success is dependent on you and your team, the project manager should be the one to deliver this message.  This situation is more common in large corporations than most would care to admit, and it can lead to constant scope creep and also a waning commitment of the project team and partnering resources.

I recently managed a large business transformation project for a retail organization where the business sponsor was not willing to commit the resources needed to complete the project.  The sales area of this organization had determined that they could use a large highly graphical computer screen to increase sales of items not displayed in the store.  When I came on board the technology team was making all screen display decisions, which meant the accountability for product success was resting entirely with team members who would not be using the product.  The business sponsor was focused on immediate revenue from the product launch, but would not spare anyone to spend the amount of time needed to determine the key product details to make it successful.

As the project manager, I had to come up with a compromise to get the sponsor committed.  The plan was to have the technology and business team members collect and manage all of the questions and design decisions into planned review sessions, where a review panel formed by the sponsor would make decisions.  The panel was empowered to make all decisions even if all of the members could not be present at each session.  Problem solved – the business review panel sanctioned by the sponsor owned the “fit” into the actual sales organization.

It is the project manager’s responsibility to educate the business sponsor on their role and responsibility, and it is more than just writing the check for the project funding.  Follow the steps below to gain the needed support and involvement from the business sponsor:

• Schedule regular “town hall” meetings between the business sponsor, the project team and any other key partners.  In these meetings the sponsor should reiterate the significance and importance of the project as well as their commitment to helping the team to be successful.

• Establish scheduled meeting routines (generally monthly) that include the business sponsor and the project team.  At a minimum, provide progress and issue report outs, change order and impact reviews for approval and project budget reviews.

• Educate the sponsor on their role in a steering/advisory/stakeholder committee.  This role is significant as they are an effective communication vehicle as well as visibility for the business sponsor.

• Conduct scheduled one-on-one touch point meetings with the business sponsor and make yourself visible to them.  Ensure you have “permission” to have unscheduled meetings when needed and constantly cultivate the relationship with the project sponsor because your success impacts their success.

Conclusion

As a project manager, it is likely that you will face one or more of the above scenarios.  Use the tips and techniques discussed here to motivate and influence your team so that they are working in the best interests of the project.  When you have fine tuned the “people” side of project management, you are on your way to becoming an exceptional project manager.

*Contributor – Deborah Barry, Executive Change Consultant

Download PDF