The Fallacy of Survivorship In Project Management
|
The term "survivorship bias" originates from wartime observations when aviation experts examined planes that returned from battle in WWII to identify where they had taken the most damage. They mapped where all the damage was found and then with this information they considered reinforcing these areas to make the planes more resilient. However, a statistician named Abraham Wald pointed out a flaw in this approach. The planes they were examining had survived, despite their obvious damage. It was the planes that didn't return—those hit in other critical areas—that needed to be studied. By only looking at the survivors, they were missing vital data on the planes' vulnerabilities and in fact had they gone ahead they would’ve reinforced areas of the planes that didn’t need reinforcing, and not reinforced areas that did. How does this relate to project management? Imagine you want to discover the secret to successful project management (and who doesn’t?). You might be tempted to analyse only successful projects and identify common factors in them (like mapping damage to aircraft that made it back). You then describe successful project management according to these traits of these particular projects and focus your training on these processes, tools, techniques or competencies. On the surface, this seems logical right? But here's the catch: by only looking at successes, you're missing out on a vast amount of data from projects that failed (the planes that didn’t return, and the reasons they didn’t return). These failures can offer crucial insights into pitfalls and challenges that successful projects either avoided or overcame (sometimes by dumb luck!). Fortunately for us the world of project management is littered with failures. In fact, it could be argued that the ‘norm’ in project management is failure – after all, most projects are somewhat unique, and subject to a myriad of constraints and risks. I’ve never shocked at those oft repeated statistics that 60-70% of projects fail, often used by people to ask what is the point of professional project management when this figure hasn’t changed over 10 or 20 years. I always think that the number is a constant because that’s just what projects are – failure magnets – and yes, that’s a topic for another post but chime in on this if you want. Success is not just a product of hard work, planning, and strategy. Sometimes, it's also about being in the right place at the right time – plain old dumb luck. Recognizing the role of luck in project success is essential. Also, don’t discount the role of external factors beyond the control of the project manager. Two projects could be managed similarly, but external factors, timing, or sheer coincidence could lead one to thrive and the other to flounder. For instance, a company might initiate a project to launch a product just when there's a sudden surge in demand due to unforeseen circumstances, making the project seem brilliantly managed and executed. Another similar project might face unexpected competition or market changes. Is it fair to label one as superior management and the other as lacking, without considering the impact of luck, coincidence, or external factors? And that’s why it’s important to analyse and learn from success AND failure. So yes, I’m saying celebrate failure as a learning opportunity. I’m not saying throw a party, give bonus’s and promotions, and advertise to your clients how wonderful you are at project failure. I’m saying, treat them as real opportunities to learn something that will help you be more successful in the future. So don’t fall into the trap of survivorship bias. We all want to be more successful at delivering projects but to truly understand project management the factors that contribute to project success, we have to consider both the winners and the losers. So, maybe at your next monthly community of practice meeting, or your next post implementation review, or your next portfolio planning session, take time to have someone present about failures and what they learned from them. Do this without judgment, compare it to what you learn from successes, and you are probably on your way to discovering what makes your projects successful (oh, and please take time to really define project success and how you will measure it – again, that’s a topic for another blog, but chime in on this if you want). |
Survivorship bias is a logical error that focuses on the survivors of a particular process, while overlooking those that didn’t make it. In the context of project management, this can lead to misguided conclusions about what it truly takes for a project to succeed.What Exactly is a PMO?
| As a consultant who works with organizations around the globe, I get to see many forms of a PMO and I get to see what works and what doesn’t. A well thought out and value adding PMO can add measurable strategic and operational value to any organisation regardless of its size or maturity. Getting the right PMO for your organization can be a challenge and I want to share with you some thoughts and observations on what exactly a PMO can be. Hopefully from these thoughts you can take some tips on what your PMO should be. Let’s start with what do the letters “PMO” stand for? Well the “P” can stand for Portfolio, Programme or Project. The “M” and the “O” generally stand for Management Office. You can add an “E”, for Enterprise, in the front to get an EPMO to indicate it stretches across the entire organization. You can have individual PMO’s that answer into an EPMO. It can even not be called a PMO at all, and there are many other names it can go by. You can call it what you want as long as the name is an accurate representation of what the function actually does. Answering the question about what a PMO can be takes a bit more time. It is not a single standard format you can apply to your organization which makes it a little hard to define appropriately. The easiest why I have found to describe, at a high level, what a PMO is, is that it should be the center of excellence, whatever that means, for professional project management in your organisation to support the current and future portfolio, program and project management aspirations of the organisation. That is a long winded way of saying that your PMO should support what you currently do but also take you into the future and a better, more mature state. At one end of the spectrum I have seen a very low maturity organization have a ‘PMO’ that was as small as a few ring binders with templates in it that were regularly updated. At the other end of the spectrum I have worked with large and complex PMO’s which can be a fully separate and resourced unit that does full portfolio management, strategic alignment, governance, project selection & reporting, and also employs, deploys, & trains all the project management personnel. Somewhere between these two extremes is the PMO that is right for you and your organization. Here is a list of functions that a PMO might consider:
What have I missed? These are the types of things to consider when thinking about introducing or upgrading a PMO:
Unfortunately, the research tells us that there are many threats to a PMO and its success. These include the following:
Just a reminder, this is just a high level introduction to the PMO. There has been plenty of research done on the topic and if you are academically minded you can easily find some serous pieces of research out there on the topic. There are also many people more on projectmanagement.com who I know would love to share their experiences, both bad and good. So don’t be afraid to reach out and find out as much as you can before deciding on what sort of PMO is right for you. |
Defining Agile
| There is a lot of use of the word agile in the organisational world. You can see it in job ads, see it in the descriptions of the way software is developed, and see it being used to describe entire workplaces and organisations. These are the four main ways I have seen it used over the past year:
What are they? What do they have in common? Let’s start with the dictionary definition of the word ‘Agile’. The definition that we find is that the word is an adjective that means “able to move quickly and easily”. I think this definition is quite accurate for each of the four uses of the word I’ve already listed. Here is a brief description of each of these four forms of Agile: Agile Software Development Agile software development following the increase in the development of software which initially started with traditional or waterfall type development methodologies. During the 1980s and 1990s a growing number of software engineers realised that there were better ways to deliver software. Instead of the process heavy typical waterfall project management approaches they were advocating a range of lightweight methodologies designed to get software developed in an iterative manner that focussed on delivering continual value in highly changeable environments. They were originally called lightweight methodologies but at a seminal meeting they didn’t like the name ‘lightweight’ so used the term agile. There are now a range of recognised Agile methodologies (Scrum, Kanban, Extreme Programming, Lean etc) and many hybrids of these. For more information about the origins of agile software development I recommend checking out www.agilemanifesto.org and www.agilealliance.org as beginning points.
Agile Project Management Agile project management takes the key concepts from Agile software development and applies them to a broader range of projects, not just software development. It focusses on delivering requirements incrementally and iteratively. Project teams focus on continual improvement and are focussed on adapting to changing requirements at any stage in the project. Agile project management uses many of the same Agile software development methodologies listed above. I’ve been lucky enough to work in both the software development industry, and also the large construction industries in my project management career. Even though Agile project management is usually intended for the IT industry I can definitely see benefits for the traditional construction industries as well.
Agile Workspaces An Agile workspace attempts to bring to the work area the key core principles of Agile software development or perhaps more specially the Agile Manifesto. There is a focus of flexibility and customisation that allows team members or staff members to work collaboratively and openly. The intention is to provide an office space that is space efficient, productive, and vibrant, and one that promotes creativity and problem solving. It is in direct contrast to partitioned workspaces or open plan work spaces. There are defined areas suitable for different purposes and different working styles within an agile workspace. The perfect synergy is intended to be teams using agile project management methodologies within an agile workspace.
Agile Working Agile working takes the concept of agile to its broadest definition and intends to provide employees with a work environment in which they can work in the way that best suits them and the organisational goals of delivering value. The focus is on work outcomes, not the hours worked. The intention is to encourage people to work in their most creative productive manner and provide the best organisational and customer value. The aim of agile working is simply to create a more responsive, efficient and effective organisation, which ultimately improves business performance and increases customer satisfaction Here is a link to a great article on Agile working http://www.nhsemployers.org/-/media/Employers/Documents/SiteCollectionDocuments/Agile-Working-Guide.pdf?la=en&hash=C2F9D66C3C434D939B18DF1561D5AAE50250C0AD
My final word on one of the greatest changes about implementing any of these forms of Agile is to ensure that team members and/or staff are fully prepared for the change and supported throughout the transition as each of these forms of Agile requires a certain attitude and aptitude from team members and staff, and the organisational culture needs to truly reflect and support the principles of agile.
If you have any questions, comments or feedback please feel free to email me. |
How to set up a PMO by Stealth
|
More and more research clearly indicates that organizations with a PMO deliver more successful projects than organizations without a PMO, yet that same research also tells us that a lot of organizations fail to see the benefits of a PMO, and some organizations are even getting rid of their PMO’s. They see them as an unnecessary expense rather than the investment that they actually are. Keep in mind that PMO is not a single standardized thing - what it is will reflect the level of project management maturity, your industry and the size, complexity and duration of the projects you undertake. It may be anything from a single ring binder full of templates through to a specific part of the organization that controls all aspect of project management. The one thing that all forms of PMO have in common is that they are the center for project management excellence in the organization. Now, we as professional project managers know that we can do our jobs much better when supported by a PMO. But how do we go about establishing one in the when top level management fails to see the benefits? How about a stealth PMO or perhaps a VPMO – the V can stand for volunteer or virtual? Here are three simple achievable steps to creating your own stealth or virtual PMO: 1. Establish a project management users group in your organization. Invite all project managers to be part of it. Then schedule regular meetings – a good idea is 4pm on the 4th Friday on each month, or a breakfast meeting - and supply some refreshments for people. Have a specific topic to talk about – it could be improving your change control, standardizing templates, lessons learned and updates to your project management methodology. Invite a speaker to attend to present on a particular topic. Have someone document the meeting and follow up on any agreed actions. 2. Get the project managers to take responsibility for documenting your project management methodology and then volunteering to carry out audits on each other’s projects. 3. And most importantly of all, when your do deliver successful projects attribute your success to the support you have received from the VPMO or users group or whatever it is you want to call it. Let the decision makers higher up see the value. Your goal is to get them to support not just a PMO but also professional project management within the organization so don’t be shy about blowing your own trumpet. Take care to first prove the worth of the PMO to practitioners and the organization before trying to get financial support for a more complex form of a PMO, or even a paid PMO manager position. Remember that this stealth or virtual PMO will be your first PMO so it doesn’t have to be overly complex. The main goal is to prove its worth and get support for a more complex one. Let me know how you go with this idea, and it you have any other suggestions for getting a PMO off the ground in your organization.
|
The Art of Tailoring: Making Your Project Management Methodology Fit
| This blog is a reminder for those who know already, an introduction for those who are not yet aware of tailoring, and general call to action for all project managers to consider ways to work smarter and more effectively thorough proper and appropriate tailoring of project management methodologies. A methodology is an appropriate, professional, repeatable, standardised and documented collection of processes, tools, technique and template for managing projects. The methodology is what you use to deliver your projects. It should reflect the size, complexity and industry of your projects. It should be based on best practice such as a body of knowledge like the PMBOK® Guide. It should be easily located and understood by all project team members. It should also be subject to the process of continuous improvement to make sure it is kept up to date with any changes. A methodology is your organisations particular collection of processes, tools and techniques and templates that you choose to use. Tailoring is the processes of choosing which of these are appropriate to use on any given project. One size doesn’t fit all. You methodology doesn’t suit my projects, but your methodology also doesn’t suit all your projects. It should also be flexible and scalable enough to be able to be used on all your projects. This must be kept in mind when developing or changing your project management methodology. Within your organisation it is the project management office (PMO) that is responsible for developing, monitoring and improving your project management methodology. When it comes to the process of developing, or changing, your project management methodology you have two main options available to you. You can choose to develop your own methodology or to use an already developed one available as an off-the-shelf solution usually for a fee. If you choose to develop your own one, the most important part for getting this right is to have people with the right level of experience, passion and commitment to make sure the development doesn’t stop half way through. Developing your own methodology is not a single event, it takes time and iterations to ensure it is correct. It also requires a champion who will commit to seeing the initial process to completion. Too many good initiatives have been left to flounder due to the absence of a champion. The benefits of developing your own methodology is that you can leverage off existing intellectual property, accommodate the organisational culture and get by in from the project management team by seeking their input on what constitutes an appropriately tailored methodology. A disadvantage to making your own methodology is the time and effort it takes to get it from initiation to working methodology with processes, tools and templates. There are many off-the-shelf solutions for a project management methodology and of the ones I have seen, most claim they can be customised to suit. However, most people don’t see this and assume that simply by taking an off the shelf solution that it will solve all their problems. The benefits of getting an off-the-shelf solution is that it is available right away and it is a known methodology. The drawbacks are that people assume that because it works for someone else that it will work for them when this is not always the case. The instant methodology does not reflect the organisational culture or industry. Also, there is no control over intellectual property and there can be a lack of buy in and support from project team members. Tailoring is “For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process. Project managers and their teams should carefully address each process and its inputs and outputs. The PMBOK ® Guide should be used as a guide in managing a project while considering the overall approach and methodology to be followed for the project.” (The PMBOK® Guide 5th edition). The concept of tailoring has grown in importance over the years with different versions of the PMBOK® Guide giving it more emphasis. The phrase ‘tailor’ or ‘tailoring’ is used 0 times in the 2nd edition, 10 times in the 3rd edition, 13 times in the 4th edition, and 11 times in the exposure draft of the 5th edition Tailoring your project management methodology is an important step in organisational project management maturity and also in getting people to use and improve your In the absence of an appropriately tailored project management methodology, people will tailor their own solutions. Here are some signs that your project management methodology is not tailored correctly.
The benefits of a tailored approach to your project management methodology are:
There are three stages to tailoring your project management methodology. The first is the initial tailoring you do to select those elements that will form your project management methodology. Here, you select from a body of knowledge such as the PMBOK® Guide, all those processes, tool and techniques that are appropriate to the styles of projects you are doing based on their complexity and size. Factors which influence the choices you make in developing a project management methodology are project size, complexity, organisation and team culture, and internal and external constraints. Once this initial process is complete you will have a methodology that is able to be used for your projects. Obviously if your projects are all largely similar then the methodology will be a fairly standardized one used without much change between projects. If however, the size and complexity of your projects varies considerably, then this first stage in tailoring your methodology will result in a scalable and flexible methodology that can be adapted to be used on all your projects. Some specific examples of scalability and flexibility include the type and size of any project charter, the range of scope definition and extent of planning completed and, the effort put into risk management and communications management. The second stage is the tailoring you do before starting a project to determine what elements of your project management methodology you are going to us for this particular project. This process should involve both the project manager and the PMO in deciding which elements of the organisations’ project management methodology are appropriate for this particular project. An easy way to do this is simply to divide projects into small, medium and large projects and have a different set of processes, tools and templates for each category. There are other, more complex ways of making these decisions as well. The third stage of tailoring is completed during the execution of the project where you are checking that the particular combination of elements you have selected is still appropriate and you are not over cooking or undercooking a project. Tailoring is an iterative process done throughout the entire project lifecycle. The PMO should have an input into this review process, and oversee and approve any changes. Adding your lessons learned about the application of your selected methodology to your lesson learned process helps other project managers in the future.
|
