Project Management Train Wrecks

Introduction

The PMO of any major organization with a significant number of projects in the project portfolio, which recognizes that “successful project” is a somewhat relative term. In addition to the traditional “triple constraint” metrics, there are other, more subjective measures that may dramatically influence a customer's perception of competency and success. Understanding and managing these perceptions, as well as tangible results, is important to the success of any project management organization. For a group dealing with internal customers, perceived success influences budgets and careers. For project management organizations interfacing with external customers, it influences revenue, and new business. This presentation will identify six key learnings distilled from the author's 30 years of project management experience – successes as well as failures – managing over 200 major projects. Those projects ranged in scope and value from small, single site manufacturing and construction projects, to a logistics project touching 200 sites across 40 countries, and a $1B telecommunications project encompassing 2000 sites. Its objective will be to, in these six key areas, and using examples drawn from the author's experiences, highlight the processes and tools that can be used by any experienced project manager to help manage problematic projects back “on track”.

Background

Organization

Although our organization has over 600 resources with “Project” or “Program Manager” in their titles, the group I work within is comprised of about 120 full-time project managers who work for external customers utilizing a consulting services model. About 80% of these project managers have their Project Management Professional (PMP^®) certification, and many have other, related technical (PE, RCDD, AIA) and vendor (CCNA, CIPT, MCSE, CNE) certifications.

Customers

While a few of the over 300 projects managed in 2004 were for internal customers, most supported the sale, deployment, and operation of products and services for SBC's large enterprise customers.

Project Portfolio

Projects managed by the group range across the breadth of the data communications landscape. Examples include:

• Multi-site, Wide Area Network (WAN) deployments for customers who are upgrading their data communications networks at many sites.
• Metropolitan Area Network (MAN) deployments for governments and municipalities who are linking agencies and departments together with high-speed, redundant networks.
• Projects for colleges and hospitals, building networks to support their campus environments and bandwidth intensive applications.
• Local Area Network (LAN) infrastructure projects for companies who are constructing new offices and manufacturing facilities that require extensive cabling, and data communications hardware.
• Projects supporting the data communications needs of city and county school systems, linking schools, libraries, and administrative offices and providing high speed Internet access.
• Federal government projects for agencies and departments who are upgrading their secure network infrastructure.
• Projects requiring expertise in the build out, consolidation, or relocation of data centres, call centres, and corporate headquarters.

The scope and duration of these projects vary widely. Some are such that a single project manager can manage two or three projects. Others require the efforts of a team of 15 to 20 project managers, while project duration ranges from just two or three months, to projects and contracts extending over five years or more.

Project Management Methodology

The internally developed tools and processes utilized by our project managers to manage projects are based on Project Management Institute's (PMI^®) A Guide to the Project Management Body of Knowledge (PMBOK^® Guide).

Applications support

The project management organization's PMO operates and maintains a secure web site, accessible to project managers through the corporate Intranet. Dial-up and high speed, secure, VPN access is available for project managers who work remotely from a customer's site. This electronic PMO, or “ePMO”, provides links to a suite of tools and templates for the project manager's use. Additionally, each active project is supported with a discrete web page that assists in organizing, storing and presenting project documentation. Customers as well as project managers are able to securely access documents such as schedules, status reports, issue logs, change orders, design documents, and CAD drawings.

Key Areas and Learnings

1) Scope/Contract Issues and Learnings

Any successful project manager or project management team will have, understand, and follow a documented Scope of Work (SCOW) and/or Statement of Work (SOW) for a project. But “the devil is in the details”. More often than not, especially on large or complex projects, there is an incomplete, inconsistent, or erroneous understanding of what's being delivered – the customer's understanding of the project's scope and deliverables, and the project management team's understanding of the same project, are not congruent – before the project even starts!

Project Scope

An understanding of the project's scope, and our part in it, is a good place to start. This understanding and agreement about what's going to be done can take the form of a contract, or may be more informal, but is always documented. There are times when the project and its deliverables support a larger SCOPE (uppercase) or set of business needs. For example, the project's SCOPE may be to deploy a suite of collaborative applications to 25,000 employees, at 200 sites, in 40 countries. Our project's scope (lowercase), as defined by the project's SCOW, is to design and install the network infrastructure that will facilitate data communications among those sites and workstations. One or more SOWs may define the responsibilities and deliverables for each of the key product and services vendors.

The Contract

The contract, or other agreement between the customer or client and the organization doing the work, also has a direct and important bearing on project health. The time to negotiate risk and ambiguity out of an agreement is before the work starts, not when the pain, cost, schedule or other impact has backed us, as project managers, into a corner. Attorneys are good for this, and can help us avoid, or at least identify and mitigate contract risk. It's just as important for the project manager to sit down, and from a common sense perspective, review the agreement's Terms and Conditions (Ts&Cs) for obvious “gotchas”. A review of all subcontractor agreements and their relationship to the agreement with the customer can be important as well. As an example, on one project our contact with the customer call for liquidated damages if certain milestones were missed, but the draft agreement with the main subcontractor doing the work did not pass through those same terms.

Required - A Common Understanding

As project managers, it is critical that we confirm that all of the key players have a common and congruent understanding of the project's scope and their part in successfully fulfilling the customer's requirements:

• The sales team working with the customer to build the deal
• The customer who has contracted with us, and more specifically, the customer's key stakeholders
• The engineers who have designed the solution
• The vendors who are providing the hardware
• The subcontractors who will responsible for some part of the work

How - The Kickoff Meeting

The ideal time to confirm this common understanding is before the contract is signed. It's imperative, however, that it be no later than the Kickoff Meeting. In fact, the Kickoff Meeting agenda should be constructed to ensure that nobody leaves the room until that common understanding is reached and agreed upon.

Some project management organizations, including ours, have a kickoff process that entails two kickoff meetings. The first is an internal meeting that includes representatives from sales, engineering, project management, vendors, and subcontractors. During this meeting, we all come to a common internal understanding and agreement on the project's scope, the work, and deliverables to be provided by each group, and the schedule over which the work will take place. The external, or customer kickoff meeting follows. Depending on the project's scope, each meeting may take several days. Without “up front” agreement on the “what” – scope, SOWs, and deliverables, the project is sure to become problematic. Of course, it's also important to have concurrence and agreement on the “how”, “who”, and “by when”.

Learnings

• Don't begin the implementation phase of any project without a common understanding of the scope, deliverables and schedule among the project management team and supporting departments, groups and vendors. Utilize the Internal Project Kickoff meeting to secure this understanding and agreement. Document and distribute the key points from this meeting.
• Don't begin the implementation phase of any project without first conducting a granular review of the project's scope, deliverables and schedule with the customer/client. Utilize the Customer/Client Kickoff meeting to secure this understanding and agreement. Document and distribute the key points from this meeting as well.
• Don't begin the implementation phase of any project without a thorough review of all contractual documents, including the signed contract itself where it exists, the SCOW, and all SOWs. Ensure that master and all subcontractor agreement Ts&Cs are aligned, that any agreed-to liability is understood, and that the contract order of precedence is defined.

2) Change Management Issues and Learnings

Complexity and ambiguity seem to be the norm for most projects today, with standard processes and methodologies the defense against chaos. Understanding these concepts, though, and knowing how to use them isn't the same as actually using them! For example, on one project, the Change Order Committee – the customer group charged with reviewing and approving Change Order Requests (CORs) – informally requested that an additional step be added to the end our standard process – an extra signature. The project management team agreed. After the first series of CORs had been approved, Change Orders issued, and the work performed and formally accepted, the first invoices were submitted for payment. The customer refused to pay because the team had followed the standard process and submitted the invoices without that final agreed upon signature. On another project, although change order management processes were developed early in the project's planning phase, they were not incorporated into the contractual agreement with the customer, which had been signed earlier. Lacking a contractual process, cautious representatives for the client, a large municipal government agency, would not agree to any changes, even those with no financial or schedule impact. The work was delayed for 90 days while a change order process was negotiated and added to the contract. On a complex deployment of new technology for a third customer, a major change order request to support procurement of additional network electronics was rejected. The project team had been pushed to begin the project prior to final agreement on details of the network design among the customer, hardware vendor and integrator. The customer argued that, since there was no approved baseline design document describing the final bill of material or functionality, there was no justification for a change order!

Required – No Loose Ends

Project managers are always pushed to cut corners in one way or another, and one common way is to agree to “crank up” the project – to meet a deadline or to satisfy the customer - without having all the details worked out. “We'll change order it when we get it finalized”. But if you don't have all of the details worked out, the best change order process in the world won't help. What are you changing “from”?

How – “As-Is, To-Be”

Use the consulting change model concept. “As-Is” defines the current, or baseline state. “To-Be” defines the desired, future state. The change order, along with the revised scope, SOW, BOM, costs, schedule and completion criteria is the tool the project manager utilizes to move the project from “A” to “B”. The change order is the road map and the car. Make sure that, before you step on the gas, you know exactly where you are, and where you want to wind up.

Learnings

• Don't begin the implementation phase of any project without a defined, documented and agreed change management process in place. If a contract is in place, the process and documents should be referenced in the contract, if not attached, just as are the SOWs.
• Make sure that the project management team has a clear understanding of the “current state”, pre-change order. Don't take the customer's word for it.
• Just as important, make sure that there is a congruent understanding between the customer and the project management team around the end state. When the change has been implemented/completed, what will be different?
• Finally, document, document, document. There's no such thing as “too much” documentation where change orders are concerned.

3) Resource Management Issues and Learnings

Each of us, as experienced project managers, bring a whole range of skills, experiences, knowledge, and “opportunities for growth” to our projects. The same holds true for a project management team. Budgeting and project priorities in today's business environment, however, means that the ideal project manager candidate isn't always the one selected. On one project, the candidate most qualified to lead the project management team worked from offices 1000 miles away, and the customer wasn't willing to pay for the travel and related expenses to fly the project manager back and forth from the project site. Absorbing the expense of relocating the resource or the T&E over the project's 24 month duration was rejected by management as too expensive. When the customer insisted on a local resource, an experienced contactor was hired. 12 months into the project's planned duration, $1M in the “red”, and behind schedule, the originally selected resource was brought in to salvage our credibility. On another project, the customer requested that the very technically competent project manager be replaced. “He doesn't understand our culture, and everybody is unhappy with him”. On a third project, the assigned PM was moved to one deemed more critical to the business. The new project manager, who took over without an orderly transition, was asked to leave within 6 months.

In each of these examples, the customer/client suffered the effect of a poor resourcing decision.

Required – An In-depth Understanding of the Customer's Needs, and a Resourcing Decision That Meets Those Needs.

The needs of the customer must come first, and it's up to the project management team to understand those needs completely. Project management competencies fall into three general areas:

• Technical skills and experience – does the project manager have technical knowledge and experience related to the work being contemplated by the customer – construction, logistics, network integration, VoIP, etc.
• Project management competency – Does the project manager have a grounded understanding of PMBOK^® Guide -based concepts and how to apply them, and experience in using the processes and tools on projects of commensurate complexity.
• Interpersonal skills – Based on importance of the project, visibility in the community, risk of failure, and customer's workplace culture, does the project manager have the “people skills” and experience to lead the project team, manage the customer relationship and overcome the organizational obstacles to project success.

The project manager is typically the customer's single point of contact (SPOC) for all things project-related, and is at the “hub” of the project management “wheel”. Taking the time to carefully evaluate and match the project manager to the opportunity is often the difference between project success and profitability, and project failure.

How – Stakeholder Interviews

In addition to the contract, SCOW, SOWs, schedule, and other tangible documentation that sets the boundaries of the project, stakeholder interviews can be a useful tool for documenting cultural, political, and organizational perceptions about the project, it's value, perceived benefits, and obstacles or resistance to the changes created by the project. So while the more familiar documents can best define the technical and project management complexities, the output from the key stakeholder interviews can help clarify the degree to which the project manager's “soft skills” will shape project success.

Key stakeholder interviews should be organized with the client organization or department, but also with those key customer business areas impacted by the project. Additionally, the project manager should understand, through similar interviews, the impact, importance, risk, and benefit to his own organization.

Learnings

• Properly matching a qualified project manager to the opportunity is a critical project success factor.
• Skills and experience to be evaluated during the selection process include technical experience/familiarity, project management competencies, and interpersonal skills.
• Of the three areas, the “soft” people skills are many times most important to project success. They are also the most difficult of the three to reinforce with training, or process, templates and applications.
• The degree to which “soft” skills will play a role in influencing project success can be highlighted though a deep understanding of the customer/client organization, culture and it's perception of the project impact and value on their daily lives.
• An important tool in defining these admittedly subjective issues it the key stakeholder interview.
• The interviews should be conducted with the customer/client organization as well as the project management and delivery organization.

4) Project Management Tools/Processes Issues and Learnings

Anyone who has studied for and passed the PMP^® exam is knowledgeable about, and fluent in the use of all of the processes and tools described in the PMBOK^® Guide, right? In the author's experience, most project managers are in a rut when it comes to the processes and tools they pull from their “bag of tricks” to manage a project. That old saying, “When the only tool you have is a hammer, everything looks like a nail”, has some truth in the project management world.

For most project management organizations, but especially for large ones, use of standardized methodologies, processes and tools promotes teamwork and collaboration, provides a framework that supports project documentation needs, and facilitates project success. Most project managers, however, have their own ways of doing things – forms and templates they've used and like, or processes that “work” for them. These tools have helped them to be successful in the past. Teams who have worked together more than once are the same way. Unfortunately, the use of these old familiar tools may leave a project manager vulnerable to being surprised by project problems, and blind to their solutions.

On one project, the project manager, a “hands on” type, evaluated and made quick decisions about the issues that arose each day. But he was very busy and only documented about 20% of those issues and decisions in the issues log. Another project manager had his own filing system for project documentation, which didn't conform to the organization standard. A year after he left the company, the project was audited and the inability to quickly produce required documentation resulted in a $250k penalty.

On a third project, although the procurement process called for developing and buying equipment from a time-phased BOM over the project's duration, the project manager agreed to procure all of the electronics (about $5M) in a bulk buy, as he normally did to avoid the risk associated with product availability and long lead times. When the project was delayed by a year and a key component became obsolete, the company absorbed a $1.5M loss.

Required

A structured environment and methodology, with supporting tools, templates and applications is needed. It is important to develop “best in practice” process and tools, with input from the project management community, then make those tools and training in their use available to every project manager, and then insist that those processes and tools be utilized on a consistent basis.

How – Document, Standardize On and “Push” Best Practices Out to the Project Management Organization

There are a series of steps that the project management organization can take to ensure the consistent use of process and tools from project to project.

• Listen to your project managers. Most project managers are bright, inquisitive and want to succeed. Tap into that experience by conducting milestone reviews as well as a project post-mortem or “lessons learned”.
• Conducting these sessions as a project moves through it's natural progression of phases captures information while it's still fresh, especially on projects with an extended duration. The format can be the same as a “lessons learned” and should be framed in a positive way. What did we do well – what actions, tasks, and processes truly benefited the project and the project manager? These answers should be evaluated for incorporation into planning for similar types of projects. On the other hand, what were the concerns – what tasks, processes and actions worked against the project, or were not anticipated by the current methodology? Those answers need to be evaluated for inclusion in continuous improvement initiatives for that project, similar types of projects, or all projects.
• The “lessons learned” concept should be applied both internally, as well as externally, with the customer/client.
• In order to institutionalize the learnings and improvements, web-based repositories offer a way to organize the information, and make it available to all project managers. It can be cross-referenced by type of customer/client (market segment), project type, technology deployed, scope and duration, or other criteria. The PMO can then push the information to the project management organization through web-based training, revisions to standard project process templates, and audits of active project documentation.

Learnings

• Make “lessons learned” sessions a standard part of each project plan, in addition to a project post-mortem. Capture the information in an open, non-threatening way (“What did we do well, and want to remember to do on the next one, and what did we struggle with and how can we avoid those struggles on the next one?)
• In addition to an internal series of sessions, capture the customer's perspective on the project and key milestones with similar sessions.
• On longer duration projects, incorporate these learnings into continuous improvement initiatives – “Here's what we learned on the first 20 sites. Let's modify our processes going forward on the next 100 sites.
• Use the PMO to evaluate input from these sessions, rank where appropriate, and incorporate into “best practices”.
• Push the information back out to the project management world through training, newsletters, chat rooms and town hall meetings.
• “close the loop” by evaluating the use of existing and improved processes and tools through the use of project reviews and audits.

5) Internal and External Communications Issues and Learnings

Project managers today are overwhelmed with information – email, Internet, calls, meetings, Blackberrys, IM. What particular pieces of information are critical to the decisions that need to be made today, or next month? What should be communicated to the customer? What should be escalated immediately? Trying to make those decision is like trying to figure out just when to “dip your beak” into a fire hose-size stream of water for a drink.

Project communications – internally within the project management organization, externally with the customer/client, and internally within the customer/client organization – is a critical success factor on every project. Equally critical is an understanding of what's important. If you get 150 emails each day, which ones really require your attention? If your 10 to 11 is triple-booked with conference calls which one will help you the most?

On one international project, the customer's decision to upgrade the network at a key Korean subsidiary office was “lost in translation”. When the electronics necessary for the upgrade cleared customs after shipment from the U.S., the delivery was refused by the office and shipped back.

On another project, a key component for a multi-site deployment began failing during burn-in at a staging facility. Since product quality was organized around monthly reporting, the information was added to the normal reporting cycle, and was not escalated for 45 days. After the issue was reported, the rejection and rework of an entire lot of material delayed the project for 4 months

On a third project, the project manager notified the customer of a major issue by email, and attached a Zip file of supporting documentation. The customer's email server rejected the message without sending a notification to the sender. The issue turned into a crisis three days later when the customer realized there was an issue after reading about it in the newspaper.

Required – Bridge the Gaps

Effective project communications usually breaks down at the “interstices” – the gaps between individuals and their supporting tools, the gaps between “silo'ed” groups in an organization or company, and the gaps between companies – vendors, contractors, and customers.

When, as project managers, we develop communications plans, we look at elements like meeting type and frequency, the format of the minutes, how issues will be captured, and what information needs to be on the contact list. What we don't pay much attention to is the interstices between individuals, groups, applications, and companies. Recognizing and then finding ways to “bridge” these gaps is critical to effective communication. How – Filtering, and “Closing the loop”

In the fire hose analogy, what would happen if the stream were pointed straight up, and you were at it's apex? There would be no pressure left, and you could take your “sip”. Similarly, if you can filter, or reduce the “pressure” of the communication – the data you receive – you can act on or respond to the remainder. Having a strong supporting organization or team can help, along with clearly defined roles and responsibilities. Additionally, defining, on an exception basis, what incoming information is most important to you and the success of the project will reduce the volume. Email programs, for example, allow rules to be defined that handle messages from specific senders or with specific topics in the subject line differently, highlighting them and moving the messages to special folders. One way to ensure that important communications or messages bridge the “gaps” is to incorporate feedback loops into your personal communications, and into the processes that support those communications. When you're face to face, that feedback can take a verbal form – “So what you're saying is…”. Other types of communications require different techniques. If you send an important email, follow up with a call. Decisions made during a conference call can be documented and framed in a follow up – “Here's what we decided, let me know if you heard differently…”. This concept – an acknowledgement that the data sent has been received and is correct – is a standard part of data communications architecture, and as a concept can be incorporated into the processes we utilize for project communications.

Learnings

• Effective project communications requires filtering, prioritization and follow up.
• An effective communications “architecture” includes a supporting organization, with clearly defined roles and responsibilities, integrated into project communications processes.
• In addition to filtering through other members of the project team, the applications we use as project managers can be structured to further filter and refine the data we need to act upon.
• Look for the “interstices” – the gaps between functions, groups, companies, and applications. Anticipate that they will be problems and build process “bridges” to close the gaps.
• Use the concept of “closing the loop” to confirm that effective and timely communications has taken place.

6) Project Metrics Issues and Learnings

Metrics are an easy way to check up on the health of a project. If the project is eight months behind schedule, and a million dollars over budget, and there have been no approved changes to schedule or scope, there is definitely a problem! In addition to the objective metrics that most project manager are familiar with, however, there are a whole series of “soft” metrics that influence a customer's perception of project success, some that are seemingly at odds with the objective measures.

As an example, On one project, the project manager reported that the scope and schedule were being met, and the costs were “on budget” - the Earned Value metrics looked good. But the customer was unhappy. Although the network cutovers were taking place during scheduled maintenance windows, intermittent outages were occurring well into the business day, disrupting operations. On another project, the project management team was meeting milestones, but an audit of the project documentation determined that that the customer, the project management team, and the engineers were all working from different revisions of the same engineering documents. On a third project, while the work was on schedule and within budget, the billing for the work was difficult to understand and not organized or formatted as the customer had requested, which would have required a manual and expensive billing process.

The customer/client's experience with a project management organization consists of two key components. One is related to the contracted products and/or services – “Did I get what I paid for?” The second component is the experience itself – “Was the organization responsive to my needs, easy to work with, and flexible when required?” There are times when, although all contractual requirements were met, on the schedule and at the cost agreed, they will not be a repeat customer – “You're just too difficult to business with…”.

Required – A Balanced Set of Metrics

The majority of our traditional metrics deals with schedule, cost, scope and quality of the deliverables defined in the SCOW and SOWs. These are, by and large, objective, measurable and results-driven. What is missing are metrics associated with the quality of service provided by the project management delivery organization, what the retail business calls the “customer experience”.

How – The Balanced Scorecard

The balanced scorecard concept has been around since the early ‘90's, and is a methodology for converting an organization's value drivers into defined metrics. It can include familiar metrics like percentage of projects completed on time and on budget, or projects released to the customer by the order commitment date, but also includes customer/client satisfaction, repeat business, and referenceable accounts. Project managers, like other managers, are held accountable for aligning their processes and efforts with business strategy.

Learnings

• The “customer experience” has two major attributes – results and process.
• Project management metrics typically address only one of the two attribute – results – but the customer's perception is also affected by the second, which is just as likely to influence the customer's likelihood of generating additional business or positive references
• The “balanced scorecard” is one tool that can be implemented by project management organizations to ensure that project management efforts are aligned with organizational and enterprise goals.

Conclusion

Successful projects don't just “happen”. They require the rigorous application of a proven methodology, supported by standard processes and tools. This paper has described six key areas that the author has used as focal points for reviewing the health of a project:

• Do we and the customer/client understand and agree on what needs to be done?
• Do we have a “road map” for change, supported by documented and jointly agreed processes, and a clear understanding of where we are now and where we want to go?
• Are the resources staffing the project increasing the probability of success, or working against it?
• Is the project management team utilizing the tools and processes identified as “best practices” by the PMO, and are those processes and tools constantly evaluated and strengthened?
• Do project issues revolve around communications problems, or have the gaps hindering effective communications been bridged?
• Is there a “holistic” approach to project metrics that work to enhance the customer experience, or are cost, schedule, and scope emphasized at the expense of “soft” metrics?

Improvements to these six key areas can only enhance customer or client satisfaction, while at the same time increasing the probability of project success and improving the project management team's quality of life.