Inside Jobs, February 24, 2009

A Tale of Two Project Teams

A business tale of what it takes to turn around troubled projects.

The year is 2005 and times are good. The business environment is vibrant and the economy is strong. Large businesses are committing large amounts of capital and resources to implement new strategies, establish new capabilities, and open new markets. It was no different at PintCo, where Jack works as a Director of Customer Relationship Management.

Jack walked into work on Monday morning like any other. He dropped his briefcase in his office, grabbed a cup of coffee and headed down the hall to meet with his boss, Brandon, about one of the company’s troubled projects. Although Jack had substantial experience, he had only recently joined PintCo after being hired away from a chief competitor. He was still learning about some of the nuances of his current employer.

After the typical morning banter, Brandon and Jack got to the topic at hand. “Jack, I’ll get straight to the point. I need to you to take over the Customer Master File project from Paul.” Brandon said. He continued, “We hired you because of your significant project management expertise. I know that you’ve turned around a lot more difficult situations than this.” Over an hour later, Jack emerged from Brandon’s office and set out to learn more about the challenge that Brandon had posed to him.

Jack was an experienced business leader and project manager. He had seen more than his fair share of ugly projects; some he turned around while others had spun hopelessly out of control. He would be able to tell very quickly how this one would go based on the makeup and culture of the project team.

Troubled Waters

Over the course of the next few weeks, Jack took over the Customer Master File project, met with key project team members, and conducted dozens of interviews with key stakeholders. It was only a few weeks since Brandon had handed the keys to him for this troubled project, and now Jack was back in Brandon’s office to give a rather stark update on the situation.

“Brandon, I’ve talked to the project team and to key stakeholders, and I now why this project is in trouble,” Jack started. “If you truly want me to turn this project around, I’ll need your support to make some critical changes.”

Brandon, a 20-year veteran at PintCo, knew what was coming. He had seen too many projects start, flounder, and then fail at the company. He didn’t want to hear that another project was on the brink of failure, but he asked anyway, “What did you find out, Jack, and what can I do to help?”

Jack drew a deep breath and began to explain his findings. “Brandon, as you know this project has been in flight for nearly 6 months now and it is already behind schedule and over budget.” Jack went on, “In talking to the project team and other stakeholders, I don’t see the situation getting better without making some pretty significant changes.”

Jack’s experience helped him to quickly identify a number of critical issues with the project, which he carefully outlined for Brandon:

1. “The scope of the project is not well defined,”
2. “The IT architects are sitting in their ivory towers and disagree with the project’s direction,”
3. “The project team is not functioning as a team,”
4. “There is a lack of clear executive sponsorship, and”
5. “Steve from Marketing is trying to manipulate this project for his own political gain.”

“I’m not going to sugar coat this for you Brandon,” Jack explained. “I’ve seen this situation far too often in my career, and if we don’t change the situation this project will fail in glorious fashion.”

Foundations for Success

Brandon knew that what Jack said was true, and he also knew that changing the situation would be difficult, painful, and potentially costly. He reluctantly agreed with Jack, and together they laid out several key changes.

“Thanks for working with me on this Brandon,” Jack said. “Just to confirm, let me summarize the changes that we agreed to implement:

• “First, we’re going to stop the current project and recreate a clear and well-defined scope and get consensus buy-in on the new scope.”
• “Second, we’re going end the architectural holy wars by assigning key IT architects to the project on a full time basis.”
• “Third, we’re going to co-locate the team and assign members to a full-time basis on the project. No more part-time participation.”
• “Fourth, Brandon, you agree to be much more visible and an active participant to drive key decisions for the project, and”
• “Finally, Brandon – you are going to have a heart-to-heart with Steve and if necessary his boss - to eliminate any political agendas that could derail the project.”

Brandon and Jack both agreed with the plan. Jack knew that some of these changes would be unpopular, but without them the project would be doomed. He left Brandon’s office with a sense of relief and apprehension. There was still a lot of hard work and heavy lifting yet to be done…
Celebrations

Six months later, Jack ran into Brandon in the break room as they both were angling for their morning coffee refill. “Jack!”, Brandon greeted Jack with a chummy pat on the back. “Congratulations on getting the Customer Master File project into pilot. By all accounts, it has been a resounding success!” Brandon crowed.

“Thank you,” Jack smiled and answered, “but you know it was pretty touch and go after we met in your office to plan the project turnaround. There were a lot of unhappy campers and several of them didn’t like the idea of being assigned 100% to the project if you recall.”

“But we quickly converted them – and now I see a project team that is hitting on all cylinders,” Jack added. “In fact, Sharon told me she was ready to quit six months ago – and now she’s happier than ever and up for promotion.” Jack explained.

“I love it when a plan comes together,” Jack said proudly as he turned to walk away and take on his next big project.

Improve Maturity with Capabilities

When projects need a strong dose of strategy & direction, leaning solely on requirements just won’t cut it anymore.

If you’ve been a part of any business project during your professional career, you’ve seen the basic formula before: Project teams analyze the current state, identify requirements, and then implement a solution that best meets the requirements. Once the solution is implemented, management turns its attention elsewhere – never to think about that specific area of the business again. This ‘check the box’ thinking can be risky business in an environment where new competitive threats can appear anywhere and anytime.

In today’s fast-paced business environment, businesses need a performance framework that can grow over time, be benchmarked against the competition, and stretch the imagination of employees and stakeholders. Although requirements development will always be a mainstay for any project management discipline, the incorporation of capabilities and maturity models can better position your business for future competition and unforeseen threats and opportunities.

Business requirements will always be a critical element in any project development lifecycle. But they can only take you so far. Requirements – to be effective – must be relatively static and defined to the lowest level possible. When the business solution is ultimately implemented, the determination whether it met the individual requirements is answered with a simple ‘yes’ or ‘no’ with little room for interpretation or improvement.

When project teams are attempting to identify requirements, whether they realize it or not, they are typically simply restating how business currently gets done. New and forward thinking requirements are difficult to identify without some external influence, benchmark, or reference point. This is hardly an effective approach for identifying provocative strategies that will position the business to win in the long term.

Leading businesses and project managers are discovering a new approach to developing – and maintaining – provocative business strategies and solutions that can grow and change over time. They utilize a capability maturity framework that serves as a blueprint and yardstick for continuous improvement. Perhaps one of the best-known and well-established capability maturity models is the Software Engineering Institute’s Capability Maturity Model, which is often referred to as the SEI-CMM or SE-CMM.

The Software Engineering Capability Maturity Model serves the Information Technology function and outlines in clear and specific terms how the software development ‘capability’ can grow and mature over time. The SE-CMM defines maturity for the capability in five distinct levels – with level 5 being the highest or most mature capability.

The capability maturity model provides three important benefits:

1. Capability Maturity Models establish a tangible yardstick for a specific business capability (such as software development) that businesses can measure themselves against. By doing so, businesses can more honestly and accurately identify their current level of abilities.
2. Maturity models identify a specific best practice level for the capability that businesses can strive to achieve. By establishing a tangible continuum, the capability maturity model allows businesses to more clearly gauge the gap between their current and desired capability levels.
3. For standard capability definitions that are widely adopted across businesses and industries, businesses can benchmark themselves against key competition.

Utilizing capabilities as a tool in your project management portfolio has other significant advantages as well. Capabilities provide a framework that can help spur innovative thinking and challenge project teams to think beyond current state requirements. Capabilities, if well defined, can also help project teams to frame out high level requirements more quickly and efficiently than the traditional blank-slate requirements definition effort. Finally, and most importantly, capability maturity models provide a framework for continual improvement; if utilized as a management tool, capability maturity models can measure progress over time and challenge employees and stakeholders to get to the next level.

While simple business requirements development has been a tried and true approach for decades, simple and static requirements can only take you so far. Leading businesses and project managers are discovering that capability maturity models can contribute to developing – and maintaining – provocative business strategies and solutions that can grow and be continually improved over time.

While capability maturity models are best known in the software engineering area, business professionals specializing in areas such as Customer Relationship Management (CRM) and Supply Chain Management (SCM) are developing and utilizing the CMM frameworks to define, develop, and measure their solutions and strategies.

It’s about time. Businesses have been relying on a simplistic model of requirements definition for decades. While this model has served them well, requirements alone can be static, difficult to measure, and often represent only the current state of business. Capability models, on the other hand, can provide businesses with a blueprint and yardstick that can identify tangible long-term goals and measure progress along the way.

Leaning solely on requirements just won’t cut it anymore.

Get PAID: A Unique Approach to Customer Experience Design

Customer experience management can be a complex animal. In order to deliver a holistic solution that works, businesses must effectively align people, process, and technology dimensions across geographies, markets, and channels.

Experienced project managers know that aligning people, process and technology is critical. There have been many business methods, tools, and techniques for aligning these dimensions, but some fall short in tying them together.

A relatively new and straightforward approach for designing holistic and comprehensive customer experience solutions is PAID Diagramming. While the elements of PAID Diagramming are relatively straight forward, the single illustrated view that it provides represents an innovative and holistic approach to customer experience solution design.

The exact origins of PAID Diagramming are not known, but I’ve formalized and refined the technique with numerous clients and projects. P.A.I.D. is an acronym that stands for Process, Application, Integration, and Data:

1. Process Layer: Identifies the high-level business process that enables the customer experience. This layer may also be utilized to represent the customer experience process from the customer’s perspective.
2. Application Layer: The application layer identifies the set of applications that are utilized to support the process layer. Simple lines are utilized to represent which application enables each discrete process step.
3. Integration Layer: The integration layer identifies the major information subject areas and illustrates the linkage between applications and data sources.
4. Data Layer: The data layer identifies the various physical or logical data sources and illustrates how data is integrated with various applications.

A PAID Diagram combines these layers in a series of swim-lanes to provide an architectural view of how processes are enabled by information technology:

THE PAID DIAGRAM MODEL

While the PAID Diagram approach may appear simplistic and straightforward, the approach provides numerous benefits when dealing with complex processes such as customer experience management:

1. Creates a Holistic View: The PAID Diagram combines process and discrete technology enablers in a single view. This provides a clear linkage between process and technology that is typically overlooked in process modeling or technology-based data flow or use-case modeling.
2. Enforces a Process Centric Approach: The PAID diagram starts with the process-layer; an approach that establishes and reinforces a process-centric viewpoint for solution design.
3. Enables Detailed Analysis: Current State PIAD Diagrams provide a holistic view of potential ‘pain points’ in the customer experience process. For example, the process layer can illustrate bottlenecks or disconnect, the application layer can illustrate capability gaps or unnecessary redundancy, and the integration and data layers can illustrate where duplicate and disconnected customer data may reside.
4. Clarifies Future State Visions: PAID Diagrams can be created to reflect the current or future state environment. A future state PAID Diagram provides a single view of how a proposed solution would enhance the customer experience process or specific capability areas.
5. Provides an Architectural Viewpoint: The holistic nature of the PAID diagram provides business and technical architects with a modeling tool necessary to align the various dimensions of the business. When applied across multiple functional areas, PAID Diagrams can be combined to create an enterprise-wide customer experience blueprint that can help to drive customer relationship management, operations, and information technology strategies.

Like most solution modeling methods, PAID Diagrams work best when the appropriate level of structure and discipline is applied to the model. To get the most out of the PAID Diagramming method, businesses should follow some basic best practices:

• Create a Process Hierarchy: PAID diagrams are based on processes. If your company doesn’t have a formal process model, create one. A more formal process model will help to drive the PAID diagramming exercise.
• Keep It Simple: Don’t try to map all processes on a single PAID diagram. Instead, break your processes and diagrams into a hierarchy so that additional levels of detail can be illustrated on a separate PAID Diagram, as appropriate.
• Don’t Over Think Technology: Don’t over think the exact structure or location of physical technology assets or databases. The intent of the PAID diagram is to illustrate enabling relationships. The PAID Diagram is not intended to be a formal IT Architecture Model (but it can help in that regard too.)
• Annotate the Diagram: The more details you can provide with each link, the more meaningful the diagram will become. For example, showing the specific data elements that are being pulled from a database will help identify potential issues or opportunities.
• Use a Standard Modeling Tool Like Visio: For Windows-based computing environments, businesses should utilize a standard business-modeling tool such as Microsoft Visio to create and maintain your PAID Diagrams.

Having helped to design, develop, and implement countless business strategies and solutions in my career, I can honestly say that the PAID Diagram is one of the most useful tools in my toolbox. In businesses where I have used this technique, nearly every one of them have adopted the method as part of their stand solution design methodology.

It just goes to show you that often the simplest of techniques are often the most effective.

Inside Jobs, January 30, 2008

Every Project Should Connect the Dots

In today's business world, implementing projects is the way that things get done. Projects are conceived and reviewed nearly every day, but not every project is created equal. Some projects can create results that go straight to the bottom line, while others languish to generate any tangible results.

Hopefully, everyone will experience their fair share of good projects in their career. Good projects that deliver what was promised on-time and on-budget and ends with a ticker tape parade through the cubicle aisles.

Unfortunately, you will probably experience a few bad projects along the way as well. Projects can go bad when they are funded and approved without a clear understanding of how, or when, they will generate value for the company. Obviously, it's important to know what your project will do for your company before you begin. In fact, every project should first connect the dots to stakeholder value BEFORE they are approved.

Nobody wants to willingly volunteer for another bad project. So, before you raise your hand to volunteer for that next project, take a moment make sure that the project covers the basics; Make sure that the project will address a critical business need and deliver tangible results that contribute to stakeholder value.

Determining if the project addresses a critical business need is subjective at best, as businesses still operate by the principle that the squeaky wheel gets the grease. Contribution to stakeholder value, however, should be an objective attribute that leaves little room for interpretation.

In order to clearly align projects to stakeholder value, we recommend that you develop a value hierarchy that describes how different activities contribute to stakeholder value for your company. Once established, the value hierarchy can serve as a framework for connecting each and every project to stakeholder value.

A well-defined value hierarchy can help to align projects with activities that generate the most value for the company. It can identify where multiple projects might be competing for the same benefit or identify where there may be a void of necessary projects. It can also help to weed out those projects that aren’t clear aligned to stakeholder value. Simply put, connecting projects to activities that maximize stakeholder value is just good business.

HOW TO CREATE A VALUE HIERARCHY

To create your own value hierarchy, begin with the highest form of value for your company, which should be stakeholder value. This represents the total value of your company to any person or stakeholder who has a financial interest. Then define the key dimensions that create or drain stakeholder value. Common value dimensions include Cost, Revenue, and Asset Value, each of which directly contribute to, or detract from, stakeholder value.

Next, define the set of value levers that influence each value dimension (e.g. revenue, cost, asset value). For example, the Revenue dimension can be influenced by adding more customers (increase breadth), selling more to existing customers (increase depth), or improving customer loyalty (increase duration).

Continue to define the value hierarchy by connecting lower-level activities to a node in the hierarchy. The final value hierarchy can be as detailed as your company requires. For illustration purposes, we provide a simplified value hierarchy below.

Take the 2007 Internet Use Survey and receive a complimentary
copy of the ClearBrick Customer Value Compass;
our complete customer value hierachy.

CONNECT THE DOTS TO STAKEHOLDER VALUE

To reap the benefits of the value hierarchy, connect each active or proposed project to the lowest level in your value hierarchy. If the project cannot be clearly connected to the value hierarchy, it should probably be redefined, repurposed, or cancelled altogether.

Connecting projects to a value hierarchy can have other benefits too. A value hierarchy creates a common language of value among various project teams, helps to align projects to the company’s strategic direction, and can help to identify areas that are either being over or under served.

Although utilizing a value hierarchy is no panacea, it can go a long way to helping your company determine which set of projects can provide the maximum contribution to stakeholder value. In our experience, companies that have learned to utilize a formal value hierarchy have found it to be a valuable tool for strategic planning, budgeting, and portfolio & program management.

You can find more information about how to develop a value hierarchy in the whitepaper titled How to Find Your Customer Value.

Project Managment: You Don't Know What You Don't Know

I have consulted with many Fortune 100 companies throughout my career. I always find it interesting how different the cultures can be, and how these differences influence the way projects get managed and work gets executed. One thing I find is that the discipline of project management varies greatly across organizations. However, I also find that project managers don't realize how much it varies, and where they sit across this variation.

What I mean by this is that project managers always believe that they are doing 'project management' as if it is a binary question...either you do it or you don't. However, what I find is that there are significant degrees of variation in the discipline, robustness and effectiveness of project management.

In some organizations, simply because there is someone who has a title of project manager, they believe they 'do project management'. However, those same organizations will lack the simple disciplines of issue, risk, scope and timeline management. In one large retail organization, they prided themselves on their ability to simply muscle through a project. They lacked the planning discipline, but thought it was OK, because they will simply work all day and all night to make a project successful. In fact, they were proud of this attribute. While this was true in small, less complex projects, it proved to scale as an approach to a very large, complex transformation project. Ultimately, this lack of discipline had a major impact on their customers.

I've also seen the position of PM minimizedto an administrative assistant of the person actually responsible for the project. In my experience, this is woefully ineffective and inadequate. The model that I have seen effective time and time again, is a project manager who is actually in charge of executing the project - with both business and IT people reporting into the PM. I also find that simply having a strong PM discipline isn't enough - because this focuses too much on the administrative aspects of a project. The softer elements of Project Management are paramount, but aren't covered by the PMI or PMP certification.

So yes, while solving business problems and improving business performance requires project management discipline. Often, however, project management discipline alone won’t guarantee success. Successful projects rely on another subtle element that is often overlooked: Effective project management. Read more in the free Clearbrick article on Effective Project Management. In this article, we draw the distinction between project management discipline and project management effectiveness and identify the key factors that contribute to effective project management.

Many project managers and organizations simply don't know what they don't know about exactly how well they do project management.