Tag: Project Management

3 Reasons Why the BA/PM Hybrid Role is So Difficult

Written by Tiauna Ross on February 20, 2017. Posted in Articles. 3 Comments on 3 Reasons Why the BA/PM Hybrid Role is So Difficult

There are many variations of the BA Hybrid role, but the Business Analyst/Project Manager hybrid is the most widely discussed.

While there may be disagreement on whether there should be a blended BA/PM role and where the two roles differ and overlap, I think we can all agree on one thing: this hybrid role can be very challenging. It is also a hybrid that is gaining popularity as organizations look for ways to become leaner and more flexible. In this article, I will highlight the top three reasons why this hybrid role can be difficult for many and some suggestions to overcome the challenges.

1. The BA/PM role requires expertise in both disciplines.

The BA/PM role requires highly developed competencies across both disciplines which require education and experience across both to execute well. The problem is, many organizations, whether intentionally or circumstantially, assume that a good BA can quite naturally take on project management responsibilities and the same goes for PMs being able to take on business analysis tasks. The reality is that while one person could do both, there will most likely be a marked difference in the level at which they execute if they are experienced in one and not the other. For example, an excellent PM with limited BA experience will likely get the project done but the value delivered may be less than initially expected by the stakeholders. Why? Because project management focuses on delivering the project according to the project requirements, but business analysis looks deeper at the meaning of the requirements and how the solution will be best implemented. A PM who is inexperienced in business analysis may take the requirements as stated by the stakeholders at face value, something that a more experienced BA would look deeper at and inquire more about. A BA with little or no PM experience may produce well-defined requirements but would likely struggle when it comes to managing multiple project constraints because they do not have the experience needed to make professional judgments that will keep the project on track.

2. This role only works well with small changes.

The IIBA Competency Model states this concerning hybrid roles, “The dual hybrid role is typically associated with small or less complex work efforts, where it is possible for a single person to perform both roles effectively.” This is true when it comes to the BA/PM hybrid and those performing these roles are certainly aware of this reality. This becomes an issue when an organization is immature in either discipline or is undergoing organizational restructuring. While it may be well understood that smaller is better with this kind of role, when an organization is not mature in performing project management and business analysis, the cost of failure and the loss of value is not easily identified. When an organization is undergoing organizational realignment, they often take an “all hands on” approach to getting things done, which may leave one person managing large or risky efforts while holding multiple responsibilities. From the outside, it can appear as a great way to maximize resources because no one truly understands the real costs of having one person doing both.

3. The role may not be well-defined or adequately supported.

Any role that is undefined or poorly defined is likely to cause problems. With the BA/PM role it can be even more evident. Many BA roles already have a lot of presumed tasks that impact the nature of their work. Many PMs have roles loaded with other responsibilities outside of project management. When the two roles are combined into a BA/PM role that is ambiguous and undefined, it can produce a lot of issues, not only for the individual in the role, but also for the organization. Many times, the BA/PM hybrid role is not even officially acknowledged as a hybrid role and appears out of necessity where the person keeps the same job title but assumes more responsibility in the other domain. These situations can also make it hard to find the right person for the role. It is not enough to simply take two full-time job descriptions and merge them together into a double job description. There must be much thought given to what they will be asked to do and what they will not be asked to do. If this boundary is not created, it will set up the BA/PM to manage their work by urgency only, because there won’t be enough time to do everything they are assigned.

Increasing the Odds of Success

To ensure that the BA/PM role is successful, organizations must pay attention to the role and what is needed to increase the odds of success. It is not enough to merely assign additional responsibilities to an existing role. Organizations must take the time to define the role considering the value they expect to receive and the inherent limitations of the role. Once the job is defined, there must be a concerted effort to keep assignments within the size and complexity that will best enable success and have mechanisms in place to measure that.

Additionally, there must be some consideration given to what will be needed to support the BA/PM. Are there other team members who can assist with tasks that would normally be associated with one or the other function? I have been successful in BA/PM hybrid roles where I had an oversight role on the business analysis side and was expected to review and guide the work of other BAs, rather than do everything myself. A successful support structure will also include access to the education, training and mentoring needed to allow those performing the role to sharpen their skills. All of these will increase the odds for success in the BA/PM hybrid role.

From the Sponsor’s Desk – Project Management Meets Design Thinking

Written by Drew Davison on February 13, 2017. Posted in Articles. 4 Comments on From the Sponsor’s Desk – Project Management Meets Design Thinking

The practice of Design Thinking has received accolades for transforming the way organizations solve problems.

At the core, Design Thinking is about driving decision making from the human perspective, where business, organizational and technological solutions evolve from a human-centered exploration.

Design Thinking practices offered by Stanford’s d.school, IDEO, IBM, GE and others are characterized by reimagining exercises, wide collaboration, rapid iteration, prototyping and testing cycles and a tolerance for failure. So, what happens when traditional project management meets Design Thinking?

In the following case, we will journey along with a project manager as he explores what an executive-mandated Design Thinking initiative means to his job. We’ll discover what he has to change to ensure the identified problems are addressed and the targeted solutions are delivered successfully, with Design Thinking as a key element of that process. Project management meets Design Thinking.

Thanks to G.A.D. for the details on this story.

The Situation

The Marketing Vice President for this North American retailer had a problem. While sales in the bricks and mortar locations were doing well, sales on the company’s web site were languishing. That was especially troubling because their competitors were showing significant, double digit sales growth through their internet offerings.

The company had over a hundred thousand customers using their loyalty card. They ran weekly email promotions to that base. They ran weekly print and online sales promotions as well. All the material featured their web site and the ease of online shopping. But it wasn’t increasing web site traffic and sales.

The Marketing VP had tried changes to their web site interfaces and functionality. He had sponsored the development of an application for customers to run on their smart phones, tablets and PCs. He had even offered discounts for first time online purchasers. But it wasn’t increasing web site traffic and sales.

Out of frustration, the Marketing VP decided to try something completely different. He had read a number of articles about a practice called Design Thinking and its ability to transform corporate performance by focusing on the customer. So he contracted with a firm that had a solid track record on Design Thinking engagements to help his organization rethink its approach to online marketing and service.

But, the Marketing VP knew this undertaking could be a sizeable project. So, he brought in an experienced Project Manager to oversee the venture. The selected PM had no experience with Design Thinking but he was a capable, trusted manager with over ten years of successful delivery and satisfied clients inside the company.

The Goal

The Marketing VP named his new project “Project Resonate” and set three specific targets:

Increase online sales activity by 30% annually by the end of year one
Deliver the solution within nine months
Spend no more than $1.5 million. That amount would allow the company to break even on the investment within one year.

The Project

The new project manager, let’s call him Robert, had heard the term Design Thinking and had scanned recent articles on the subject but had no in-depth understanding. So he went to work, reading, researching and discussing the subject and his role in managing a Design Thinking initiative. He met with the Design

Thinking Facilitator (DTF) assigned to Project Resonate by the contractor and was thrilled with her level of expertise and her thoughts on how their roles would operate. They agreed to the following:

Robert, as overall Project manager, would be accountable for:

Managing the relationships with the project sponsor (the Marketing VP) and other key stakeholders.
Defining, implementing and running the governance practices reflecting the company’s current dictates, including appropriate processes and practices. On this project, Design Thinking would be one of those.
Developing and managing the change management plan.
Developing and managing an overall project management plan.
Planning and tracking project financials.
Reporting on project status to all interested parties.
Identifying and supplying needed resources and facilities.
Developing and managing the risk plan.
Developing and operating change and issue management processes.
Developing and running the communication plan.
Identifying and socializing lessons learned.

The DTF, as the primary Design Thinking resource, would be on the hook to

Articulate the objectives for the Design Thinking effort and the problems that are being addressed.
Design and plan the group processes.
Select the tools that best help the group progress towards the desired outcome.
Guide and control the group process to ensure that:
- There is effective participation,
- Participants’ boundaries are challenged,
- Participants realize a level of mutual understanding,
- Participants’ contributions are considered and included in the ideas, solutions and decisions that evolve,
- Participants take shared responsibility for the outcome.
Ensure that outcomes, actions and questions are properly recorded and actioned, and appropriately dealt with afterwards.

With their respective roles and responsibilities out of the way, Robert and the DTF worked together to develop the approach and plan for the Design Thinking stage. The DTF used a five step approach to elicit and prove potential solutions, with opportunities to iterate at each step as often as needed.

They identified the participants who would be needed, including actual customers and representatives from the business and technology units affected. They drafted a message for the Marketing VP to send to the target participants explaining the challenge the company was facing (in customer terms) and asking for their assistance. They planned the initial workshop – a four day affair. They mapped out the timeframe for the first cycle and booked the facilities to accommodate the workshops and reviews. They also agreed to limit the scope in the first session to three high level goals (Epics in Agile parlance).

Design Thinking Process

And so the work got underway. Early on, Robert experienced an aha moment. As he watched the Design Thinking efforts unfold, he realized Design Thinking was just another set of skills and practices that could be leveraged to help solve a problem and deliver a successful outcome. Of course, it was a vital practice because it set the stage for everything that would follow. But, in reality, from a project management perspective, it was no different from any number of other essential skills and practices, including agile software development, lean/Six Sigma and other business analysis and design approaches, data management, technology architecture, programming and testing in all their forms, change management practices, and so on. They were all best practice based learnings that could deliver amazing value, depending on the nature of the project. They all deserved a place in the project manager’s tool box.

The Results

The Design Thinking effort on this project produced three high level goals and a number of prototypes over six weeks. Three of the prototypes went on to be developed and released into production in three sequential releases.

The project was completed in a little over five months at a cost of $650,000. After twelve months, web site hits had more than doubled and sales had increased by over 50%. Not bad for a Design Thinking first try!

Perhaps the most significant benefit from the project was a lasting passion for the process. The customers involved were truly excited by their experience. The company capitalized on that excitement in their advertising and promotion, with their customers’ approval of course. The company’s participants, business and technical staff alike, loved the energy and excitement of the problem solving and creative processes and demanded the same experience in follow-on projects. The Marketing VP insisted on Design Thinking front and center in his future endeavours. Others in the executive suite took notice. Design Thinking became a company obsession.

How a Great Leader Embraced Design Thinking

In most “traditional” projects, the target solution is known. The challenge is to figure out how best to deliver and get it done on time and budget. In a Design Thinking world, the challenge is different. Of course there will be some thoughts about the possible “solution”. But the real emphasis is on collaborative exploration leading to rapid prototyping and human-centered testing. It is a voyage of discovery, marrying customer, business and technology perspectives to deliver a solution that satisfies.

Robert’s early realization that Design Thinking was just another essential tool to add to his tool box was a breakthrough. It made the inclusion of the Design Thinking effort in his project just a normal part of his PM job – always select the best tools available for the task at hand and adapt them as needed. The experience also cemented in Robert’s mind his top eight beliefs – for serving his clients well and getting maximum enjoyment out of every assignment:

Understand the customer’s point of view
Collaborate with all stakeholders
Emphasize the journey, not the destination
Ensure the people, tools, services and resources are equal to the task
Be adaptable
Embrace risk, accept ambiguity, learn from failure
Iterate
Rapid delivery is essential.

So, be a Great Leader and put these points on your checklist of things to consider so you too can achieve great results. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

Project Management in a Lean Manufacturing Environment

Written by Pieter Den Daas on February 1, 2017. Posted in Articles. 7 Comments on Project Management in a Lean Manufacturing Environment

While many scholars have focused on studying LEAN and applying lean thinking and concepts on traditional project management…

(e.g. Basit Aziz 2012), very little is written about how project management is already being conducted in a lean environment. After all, lean manufacturing was never a ‘project management free’ environment. I personally joined a manufacturing company within the automotive industry 2,5 years ago and started running various improvement projects within their ongoing Lean Transformation program. As a result I have experienced first hand the differences between ‘traditional project management’ and ‘project management in a lean environment’. It is clear that project management is an integral part of lean transformation; without a project management approach there is even no lean transformation or continuous improvement possible. I experienced myself that for various reasons (a.o. stringent time requirements and a clear project derivation process) a different (‘leaner’) project management style is applied simplifying many of the traditional project management processes and increasing overall project effectiveness.

The History Of “Lean Project Management”

Ever since the success story of Toyota and the Toyota Production System (TPS) became commonly known to the world, “lean” has become increasingly popular. In the past decades, many companies in different industries have adopted (part of) the TPS concepts and have been able to experience first hand the benefits of applying lean principles and thinking in their organization, not in the last place by increasing value through increased productivity and waste reduction (Liker 2004).

Since then different project management scholars have also studied lean principles in a quest to improve project management practices by adopting aspects from the lean philosophy, yet with mixed results. Studies that focused on project management within the construction industry show clear application potential for lean concepts within project management AND consequently showed the benefits of applying lean in the form of improvements in value generation for clients and less waste in the process (Ballard and Howell, 2003), while other studies have more difficulty showing direct application potential and benefits (Aziz 2012). The term ‘lean project management’ was even born, yet till date no commonly accepted definition of this term could be found (Coster & Van Wijk, 2015, Basit Aziz, 2012).

One immediate observation here is that when one views project management as the production system of a company, as is the case with construction, the application of lean principles is more obvious. After all, such project based production systems include manufacturing (related) processes such as assembly and material supply, which can obviously benefit from lean manufacturing concepts.

With many other kinds of projects such as a software delivery project, an improvement project of an existing process, or an integration of a new business into a service organization, the applicability of lean concepts becomes less obvious and its potential benefits less clear.

Interestingly enough, most, if not all, studies so far always took the approach to study lean concepts and thinking and then try to apply these concepts to traditional project management. Surprisingly little to no research is focused on how project management is already being conducted within a lean environment.

After all, lean production was never a ‘project management free’ environment. On the contrary, projects in different size and shapes form an integral part of any (successful) lean production system. The A3 method, for example, is essentially a project management method and the Small Group Activity (SGA) improvement teams are essentially project teams (Liker 2004).

I have personally managed various improvement projects the past 2,5 years with a global (tier 1 and 2) manufacturer of automotive parts, following their lean methodology and believe there are clear takeaways that could be applied in general to project management.

Case Study: Project Management Within Lean Manufacturing

The company in question is actively driving a lean transformation program inspired by TPS. A crucial element of this program is that a fixed number of improvement cycles take place every year (2 – 4 per year, depending on the ‘lean maturity’ of the manufacturing location). Each cycle has a fixed start and end date during which a certain amount of improvement projects take place. The topics for the projects are decided at the start of each cycle, following a structured derivation process based on the latest business requirements, resulting already in quantified target conditions for the projects. An often-used method of such a derivation process is the use of a KPI-tree.

Representation of all departments and management layers are present during this kick-off, and will continue to meet monthly during fixed ‘lean transformation days’ until the closure of the cycle. Project progress and status will be discussed in each of these sessions. The program is further characterized by making use of global standard templates, such as a standard layout for weekly presentation boards and -last but not least – a standard process to hand over the project outcome from the project organization to the line organization in a proper and structured way that includes a joint evaluation period of affected KPI’s.

Project management and execution in such a setting implies a different approach and carries various advantages compared to traditional project management:

1. Clear and Simplified Scope Management

As mentioned, project targets are set immediately during the kick-off of the new cycle – already setting clear boundaries to the project scope. The improvement cycle further more poses a strict time constraint, which is acknowledged by all involved, which creates a clear incentive to keep the scope small. One can even say that scope is adjusted to the available time, since the main goal is to implement an improvement within the available time. “Slice the elephant” is an often-heard remark in this context, and there is strong focus and support to stick to the project objective to enable a timely completion of the project. In case of doubts during any project phase, e.g. on which direction to take or to include a certain deliverable to the project, the main question asked is always: “will this contribute to reaching our target condition?”. If the answer is “no”, it will not be added to the project scope.

2. Reduced Complexity in Stakeholder Management

The project derivation process involves the key management stakeholders at the factory. Hence the management buy-in is there from the start, implying no need for additional steering committee or sponsor approval of the project. In fact, there is often no need at all for establishing a steering committee for these improvement projects. Moreover, since the projects are derived from the overall business requirements, there is much less need to convince other stakeholders: after all, the same business requirements apply to all of them, and the question “why do we do this project” is immediately answered.

3. Simplified Communication Management

Project updates to the entire management are provided on pre-defined moments during the improvement cycle (known as the lean transformation days). The methodology in place further dictates the used of weekly presentation boards following a pre-defined template, based on which a weekly project update is presented to the key stakeholders of the involved functional area (e.g. logistics or manufacturing). Hence there is no need to establish a communication plan during the project initiation phase. The weekly presentation board furthermore contains a fixed content structure to steer that the right content is being presented.

4. Crystal Clear Closing Processes

The methodology applied in this company includes a well structured, standardized process to both hand over the project outcome to the internal customer (often the line organization) and to monitor and stabilize the new or revised process after go-live. This process (or actually it’s a mini system on its own) includes a separate handshake meeting where the project organization reviews together with the line organization any new applicable working standards and where the project organization proves the new solution actually brings the desired benefit based on a previously done validation. Based on this validation the project is officially handed over to the line organization, which is formalized through the actual signing of a handover document.

After this handover the project is not closed yet. The ownership has changed to the former internal customer, and for a pre-defined period (usually a 2-4 weeks) the teams jointly monitor performance of the project outcome. Once the performance is within the pre-defined stability criteria, this last project phase is closed and the project outcome becomes part of daily management.

Conclusion and Key Takeaways

In my experience, applying the lean project management approach as described here hugely increase overall project effectiveness and efficiency. Although this approach is primarily applied within a manufacturing environment, there are several key takeaways that will apply in any business environment.

Have a clear “Why?” from the Start

In this approach the ‘why’ is answered during the project derivation phase and is immediately acknowledged by the management, since projects are derived by the management from the actual business requirements. Having a clear ‘why’ facilitates buy-in and support and can simplify stakeholder management.

Focus and Scope, Scope and Focus

Such an obvious one considering the project management triangle: Time is fixed in this approach, creating a strong focus on defining a realistic project scope AND helping the organization to stick to the scope. Needless to stay that having a realistic scope that everyone commits to will benefit any type of project! When in doubt, answer the question “will this contribute to reaching our project objectives?”.

Using A Clear Hand Over and Closing Process

For me personally the closing phase has always been one of the most challenging phases of project management, and making use of available standards in this regard has hugely improved the time and effort needed during this closing phase.
The methodology applied in this company includes both pre-defined handover conditions and dictates the crystal clear formulation of closing conditions (stability criteria). Project hand over and closing then becomes based on measurable criteria, with no room for arguments or different interpretations.

References
– Aziz, Basit, “Improving Project Management with Lean Thinking?”, INN Division of Project, Innovation and Entrepreneurship (PIE), LIU-IEI-TEK-A—12/01272—SE, Department of Management and Engineering (IEI), Institute of Technology, Linkoping University, Sweden, 2012
– Ballard, Glenn and Howell, Gregory A., “Lean project management”, Building Research and Information, 31(1), 1-15, 2003
– Coster, Coenraad and Van Wijk, Sjoerd, “Lean project management; An exploratory research into lean project management in the Swedish public and private sector”, Master thesis, Umea School of Business and Economics, 2015
– Gabriel, Eric, “The Lean approach to project management”, International Journal of Project Management Vol. 15, No. 4, pp.205-209, 1997
– Harsha N. and Nagabhushan S., “Enhancing Project Management Efficiency using Lean Concepts”, IOSR Journal of Mechanical and Civil Engineering, Volume 8, Issue 4, pp. 20-22, 2013
– Liker, K. Jeffrey, “The Toyota Way; 14 management principles from the world’s greatest manufacturer”, McGraw-Hill 2004.
– Tan, Willy, “Managing Lean Projects: Understanding the Structures of Lean Production”, The International Journal of Construction Management Vol. 11, No.3, pp. 67-78, 2011

Project Initiation Documentation – What’s the Point?

Written by Phil Jacklin on January 31, 2017. Posted in Articles. 9 Comments on Project Initiation Documentation – What’s the Point?

Have you ever written a PID (Project Initiation Document)? Did you get any value from it? Did the project?

Is the PID just a bureaucratic process, or is there any value in it? Can we do something different and get more value?

Any project initiation document, or process, will only add value if at least one of the following things is true:

It strengthens the quality of thinking before the project
It gets read by somebody who believes it added value to them
It is used as a reference point, by everyone, and accepted as ‘the standard’ for what is to be done.

Let’s look at these, in reverse order.

1. The PID as a reference point

I have rarely seen project initiation documentation used as a reference point or to hold people to account of an approach, agreement or a deliverable. Where I have seen attempts at this (“In the PID, we said we were going to do it this way”), I have seen easy rebuttals explain the folly of the concept (“but things have changed, and you need to change your approach as a result”). Some would argue that if you keep your PID up to date as things change, it is still valid. I would argue that project teams are terrible at keeping documentation up to date. Let’s stop pretending we are going to do this and find a better way and if the PID is continually updated to reflect reality, is it an initiation document, or just the current view on what we are going to do? Having a current agreed view on where we are going to might be useful. A PID-style document might not be the best way to do this.

What are the alternatives? Personally, I like meeting minutes the most. I like sitting down with the people that might be the readers of a PID and instead, having a discussion. This meeting creates a two-way process open to cross-examination and debate (much more so than a document). Circulating minutes of the outcome keeps a record of what was agreed, and no-one needs to read a dry boring text. As things change, we discuss them again and circulate minutes again. Our documentation is up to date. However, more importantly, the people involved know what is going on rather than interpreting an understanding from a dry document. I find this approach eases understanding (the most important thing) is quicker (project managers like faster) and can be used to hold someone to account (“in the meeting on XYZ date, you said…”).

2. People who read the PID get value from it.

For this to be true, firstly, the right people have to read the PID. That means not only the sponsor or governance functions but project members and other stakeholders. This does not happen. We are kidding ourselves if we think it does. For those that do read the PID, they read the sections that they are interested in or perceive as relevant to them, often missing out important context as a result. That is not to say that some people do not read the PID. Of course, some do. However, it is not read as widely as the information should be disseminated and understood.

For the PID to deliver value, the readers have to understand its contents. The project teams that produce PIDs are often not professional technical writers, and their PIDs are full of ambiguities, contradictions and open to interpretation. It is impossible in this scenario to be certain that the few people who read it, get the value from it that you intended.

Again, that does not mean no-one gets the expected value from reading the PID. It is only fair to assume that sometimes, a percentage of the people that read the PID, get the value intended from reading it. The problem is, that on projects you need everyone on the same page. The people that have read the PID and have interpreted something else, and the people that have not read the PID and have incorrect assumptions and thoughts, are a significant problem.

I do not think the solution to the problem is writing better PIDs. I do not want my project managers to become professional technical writers. I want them to strengthen their project management skills. Given the limited utility in the PID, in adding value to its readers, maybe its time we stopped writing PIDs. Instead, use the first governance meeting to present the PID contents to the governance group, use a project kick-off meeting to do the same to the stakeholders, use the first team meeting to do the same to the project team. Now everyone has the same information. Moreover, you can do this without writing the PID.

3. Strengthening the quality of thinking

If we look at the sections in a traditional PID very few of them, have content which is a foregone conclusion. That means thought (and often discussion, group-ideation, and compromise) are needed to produce the contents. Unless a PID is produced in isolation (which it should not be), it is very hard to argue that the process of producing a PID does not improve the quality of thinking about the project. It evidently does. Hang on! Have we just re-asserted that a PID is useful after spending the last 10 minutes saying the opposite?

The process to produce the PID document is where the thinking happens. The process and discussions add value. However, you do not need to produce the document at the end. The document does not add value. Yes, we need to capture the salient points and disseminate the learning, but a document is not the best way to do that. Instead of writing, think visually. Let’s have schematics and mind maps. Instead of hoping the document is read, let’s present the document. Let’s have more judicious use of meeting minutes as documentation. Let’s stop wasting our time writing PIDs and improve the wider understanding of the project by spending more time managing our projects.

In Summary

The main problems of the PID are that it is not a good communication tool. Written communication should be low on the list on a project, it’s open to misinterpretation and misunderstanding; it takes time to produce. Time that adds little value; (iii) the PID is not read. If it is, it is not read in a way that there is a shared understanding of what the project is going to do; (iv) project teams are bad at documentation and don’t keep it up to date and (v) whilst the process of writing a PID forces some critical thinking about the project that adds value, skipping the PID, does not mean we need to skip those processes too. Instead, maybe we should have the meetings and discussions to create the PID content but present rather than a document, minute rather than read and move quicker rather than spending time writing.

Project Failure: A Catalyst for Success

Written by John McGrath on January 30, 2017. Posted in Articles. 5 Comments on Project Failure: A Catalyst for Success

There have been huge advances in project management in the last 20 years, but the elephant in the room is the issue of Project Failure.

Success rates are not improving and the metrics surrounding project failure have been disturbing for decades — at least 50% of projects do not deliver on their promised results.

These failures can cost hundreds of thousands of dollars – and into the millions – for very large projects. Also the lack of program management can cost companies millions of dollars in cost deviation. This is important because, over time, the value of your corporate brand and enterprise success rate are related.

The causes of project failure are well known, predictable and have not changed over several decades. Projects and organizations continue to be impacted and do not seem to be able to create the environment in which projects can succeed. It would seem that organizations have a fundamental inability to learn the lessons of project failure.

There are many causes of project failure and every failed project will have its set of issues. Sometimes it is a single trigger event that leads to failure, but more often than not, it is a complex entwined set of problems that combine and collectively result in failure.

This inability to learn from project failure is across all industries and sectors and includes many of the most successful organizations on the planet. The financials of failure are staggering and a complete industry has emerged to address the reasons for failure, which are as predictable as the next dawn.

We also often realize with the benefit of hindsight that most failed projects were exhibiting early warning signs and there was sufficient opportunity to respond but the signs were not acted upon in a timely fashion.

The definition of success or failure is not as straightforward as was once imagined. We are now very aware that project success cannot be adequately defined within standard parameters: completion within time, cost and performance expectations.

Cost and schedule performance are still important but the perception of project success now also includes:

Meeting the functional or technical specification
Meeting the business case
Engaging with stakeholders

Failure is not comfortable to embrace but it can often be a catalyst for success, especially if project failure comes early in product development and is accepted by all involved as a way forward.

Research shows that about 50% of projects fail because of the lack of visibility over the entire spectrum of the project management process. Take, for example, software development or the creation of a new medical device. Management of the project may involve numerous teams, each dedicated to a certain aspect of the process. However, they are operating in silos, each with its operational style and strategy for success. If these teams do not communicate effectively, the result is often a failure to deliver a successful product, often due to cost overruns or relevance to the target market.

Why Projects Fail

When projects fail, hindsight often reveals that issues were bubbling up – but ignored. These issues may include a lack of hands-on project sponsorship, team leadership, lack of resources, inability to manage change, and lack of communication. Lack of communication is the basic culprit because, without communication among project teams and leaders, there’s no clear visibility into the development process and thus what we call no “single version of the truth.”

However, when a failure occurs early in the project lifecycle, it is because of clear communication among project teams, leading to that single vision of truth. Early failure triggers positive change management and the revamping of strategies, providing a window to a successful result before massive dollars and precious resources are needlessly spent.

Effective execution needs effective planning, which includes not only tools but most importantly, human interaction. This is the art and science of project management – tools and people skills that give total visibility to the entire process.

Developing Hybrid Methodologies and Organizational Procedures

Often organizations think they can just apply off the shelf methodology – lean, six sigma, agile – and just simply apply them to the organization. While these are all good standard practice methodologies, by recognizing the relevance of each and applying them to internal procedures and the organizational toolbox, these ‘good’ methodologies become best practices – and thus a hybrid approach.

There is no magic wand for good practice project management. It takes consistent effort, applying lessons learned from other organizations or international best practices. It takes the entire team – from the C-Suite right down to the project level – to drive success. Everyone must be involved.

Project governance needs senior management support and they must understand the basic tenets of project management and the specific role that they play in the strategy. This group becomes particularly important when change management is necessary. Change rarely occurs horizontally but must come from the executive board, which often gives the go-ahead to drive that change to all project teams. It is important, therefore for the executive team to get on board with the project management scenario at the earliest stages and meet regularly with the teams. This provides the harmony and synergies necessary to manage risks, institute necessary strategic changes, and eliminate unshared silos of information.

Creating a Structure for Success

Leading the effort should be an enterprise project and portfolio management approach, which provides structure (including gate reviews and milestones), standards, reporting procedures, training and team management. A Project Management Office (PMO) can be the backbone of a successful project management approach by assuring that project delivery is managed in a controlled way. Its focus is:

Governance – guidance that decisions are made properly – by the right people with the best information, audits or reviews that assure accountability
Transparency – accurate information to support the “single vision of the truth.”
Quality Assurance – eliminating bureaucracy, providing training and mentoring – making it easier for teams to do their jobs.
Eliminating redundancy – creating a knowledge base for templates, best practices and lessons learned.
Reporting – management of documentation, project history, and risk analysis.

While structures may differ depending on the organization, there does need to be a central point of management that fits easily into the organization’s culture, takes into account the resources available and is the guardian of enterprise portfolio management tools. There may be one or more experts in the PMO who supports project managers and their teams with project management software.

This office may also manage a portfolio level dashboard that provides a type of helicopter review of the project as it moves forward. This dashboard plays an essential role in transparency, providing a comprehensive look at the myriad of details that are involved in project success and how each of those areas is moving forward – or not – in seeking achievement of the end strategies.

Setting up a PMO can be a large undertaking and a considerable upfront investment that must eventually prove its worth, which means a thoughtful approach is the best one. Depending on the time available, it may be helpful to begin the process slowly offering key services and building up as necessary to support projects in the pipeline. This is not unlike the approach that is taken in developing projects by phasing in activities to gain buy-in by stakeholders and identification of problems early before they become unmanageable, i.e. embracing failure as a way to move forward with a more successful strategy.

Gaining support from the executive level, as mentioned previously is key, but only one part of the equation. Seeking support from stakeholders is also critical. Clear communication as to the benefits of the office and its tools is a must and can be delivered in team meetings or one-on-one interactions with important influencers. Moreover, if there are stakeholders who do not seem to agree with the way forward, a special effort needs to be made to create a positive attitude for the benefit of the entire team.

Clear processes are essential but the recognition that these processes may change over time in response to new information or direction reveals the need for a focus on change management. Rather than a flurry of changes that users need to absorb on an ad hoc basis, setting up a recurring plan for review of processes and amendments eases transitions and makes for a smoother implementation.

Finally, stakeholders need to be aware of the long-term benefits of the office but it’s also helpful to show immediate benefits of the PMO to the organization. Depending on the complexities of the projects, it may take some time to the assess the full value of the office but there are a few ways to show progress. For example, introducing templates to standardize processes makes it easier for users to report their activities and gain visibility. Gaining buy-in from project managers on software solutions also can help elevate a positive view of the PMO.

Early Failure Builds Success

Early failure builds a pathway to success. However, early failure can only occur if a strong transparent PMO is in place that focuses on leveraging organization tools, dynamics and culture and that recognizes the importance of human interaction. Communication, transparency, and clear direction are key to a successful implementation that’s built on knowledge transfer and pipeline visibility.

About the Authors
John McGrath, PMO Consultant and Project Management Lecturer at Dublin Institute of Technology and Philip Martin, Founder and CEO of Cora Systems