Work in Project Management long enough, and eventually you will come across everything - this will include having a Project you were working on cancelled. This can be a difficult process because we are often personally invested in Projects, and seeing all that hard work being seemingly be in vein can be difficult. In this article series I give some considerations to cancelling projects, discussing if it should be done, why it should be and how.
Firstly, today I will look at the question "Should Projects ever be cancelled?" Quite simply: Yes. The alternative is to suggest that all Projects, no matter how warped, off-track or irrelevant they have become, should be permitted to go on indefinitely. That clearly doesn’t make sense, so we need to accept the hard truth that cancelling a project is sometimes the correct decision. However, rather than seeing it as a purely negative activity, I suggest that cancelling Projects should actually be seen as a sign of strength. There is always the temptation to continue to throw good money after bad, to keep plugging away at something for just a bit longer, work a bit harder etc. But to have the courage to go against this and make the decision to end the project is tough – but such is the nature of leadership. It requires the ability to emotionally disconnect from the project and look at the big picture, consider the facts at hand and make a clear decision. So whose responsibility is this decision? Well this will depend on the organisational structure, but essentially the Project sponsor, sponsoring group or body; this may be the Programme Manager, a Project Sponsor or a Project Board. If this isn’t clear within your organisation then this potentially points at bigger problems, and even hints at how the project may have found itself in this position in the first place. The Project Manager themselves shouldn’t make the decision, instead they may identify that they don’t think the project will meet its desired goals, and communicate this to the higher decision making body for review. So, why would a Project be cancelled? In my view it can one of two main reasons: It’s not the right project any more, or the project isn’t being done right. In the next articles in this series I will look at each of these in turn - stay tuned! In the team time, have you ever worked on a Project that has been cancelled - or even had to decide to cancel one yourself? Stay Healthy! Project Health Check - projecthealthcheck.org
0 Comments
PRINCE2 is a popular UK Project Management methodology, that continues to gain traction in other locations around the world. Now managed by Axelos, it is part of a comprehensive and integrated best practice suite along side other methodologies such as Management of Risk (M_o_R) and Managing Successful Programmes (MSP). As such, is provides as alternative to the Project Management Institute's (PMI) A Guide to a Project Management Body of Knowledge (PMBOK), and it's Project Management Professional Qualification (PMP). Since the author holds both the PMP and PRINCE2 Practitioner Certification , it can sometimes be insightful to compare and contrast the two approaches to see what stands out in both.
The author always thought of the PRINCE2 "Themes" to be equivalent to the PBMOK "Knowledge Areas"; a specific sub-disciple of Project Management that was important throughout the lifecycle; for example they both have "Risk" and "Quality" in common. Then there is the PRINCE2 "Processes", equivalent to the PMBOK "Process Groups" - essentially the flow of phases throughout the Project Life cycle. They are both broadly like any good book or film, in that they have a beginning, a middle and an end - with of course a bit more complication along the way. But PRINCE2 has a third component: "Principles". I don't think PMBOK really has an equivalent, so I think PRINCE2 has an edge here; but what actually is a "Principle"? Without turning to the dictionary, I would instinctively think of then crudely like a "guiding beacon". They aren't detailed processes or procedures, they aren't step-by-step plans or rigorous methods. Instead they are are simple but critical focus points which must then permeate everything else we do in Project Management, something that we strive both toward. Why are they useful? Simple: because once you've got your PMP or PRINCE2 exam in the bag, that old textbook is transition into phase 2 of it's lifecyle: dust collector. You'll apply these methodologies competently of course, but you'll soon forget what precisely is actually in section 7.3.6.1 of the PRINCE2 handbook. But Principles are different; short and simple, if you forget all of the other detail and just focus on remembering them I don't think you'll then go far wrong Ok Project Health Check you've got my attention, maybe these Principles could be useful in my Project. Tell me about them! Well this is just an initial insight, with our intention to focus on them in future articles - exploring our perspective and add some real life experiences along the way. PRINCE2 Principles
What are your thoughts on these Principles, do you agree with them and can you think how they have played a role during your own Projects? Also, do you think anything is missing? Let us know your thoughts in the comments below! Stay Healthy! Project Health Check - projecthealthcheck.org Agile is a methodology which is getting more and more traction in the IT industry, to the point where the word is agile is thrown around out of context and with incorrect capitalisation. There are many variants, but a feature now common to many is the idea of a daily Scrum meeting to manage the work. In our experience, how this meeting is planned and executed will set the tone for the entire project, and how effectively they embrace the true Agile approach. Will it be truely Agile, or just "Agile", or even Watergile?
We've seen it done well, but also sometimes sickeningly badly - and made our own errors along the way. Here are our top tips for effective Scrum meetings:
Do you disagree with any of these, or would you suggest any others? Let us know your thoughts in the comments below! Stay Healthy! - Project Health Check projecthealthcheck.org We’ve said it before and we’ll say it again, Project Managers (PMs) live and die by the Plan. The entire purpose of the Start-up Phase of a Project is to produce a comprehensive Plan for the Project; consisting of an integrated Performance Measurement Baseline (Time, Cost, Scope) and an associated Project Management Plan to monitor and control it. Once the planning is complete, the Project shifts into the main Execution phase which will form the vast bulk of the timeline. The Project should then be reporting its status regularly to senior management via a Status Report, as part of its overarching Governance arrangement. So far so good; but when an organisation is orchestrating its status reporting process, what does it need to consider?
We’ve recently been involved in a review and update to the Project status reporting and governance structure for a major organisation with circa 150 Projects live projects at any one time. When you have that many Projects, the Project status reporting process needs to be effective and efficient to ensure the Organisation can “see the wood for the trees” – where does it need to focus its limited time and resources? Below we’ll outline up some basic high level considerations which we consider to be important; look on for more details on some of these points in future articles.
So there you go, some basic high level considerations for Status Reporting and Governance that we’ve used. What other considerations can you think of for designing Project Status Reporting processes? There are many other factors of course, and we may get on to them in the future! Stay Healthy! Project Health Check - projecthealthcheck.org Lean Six Sigma, a management buzzword that seems to persist and many don't understand. But what is it and how is it related to Project Management? Lean Six Sigma is an approach for Process Improvement Projects, combining many different conceptual tools depending on the situation. Essentially Lean Six Sigma is a fusion of two ideas: "Lean" and "Six Sigma":
Lean Lean is a approach that seeks to eliminate Waste during a production process; it originated in Japan on the production lines of Toyota. It tries to make a process as efficient as possible, to reduce excessive costs and time - meaning the customer get the product they want faster and cheaper, the company improves their margin. It identifies seven categories of Waste which should be investigated and eliminated (though others have since been suggested):
Six Sigma Six Sigma looks to improve the quality of the output of a process by reducing the variation of the output; it was introduced at Motorola in 1986 and resulted in $16 billion of savings. The term sigma comes from the statistical concept of standard deviation of the normal distribution; if points are normally scattered about a mean then one sigma is defined such that it would capture 68% of data points, 2 sigma would capture 95%, 3 sigma 99.7% etc. Six Sigma has a strong statistical focus, and defined in purely statistical terms a Six Sigma process is one in which 99.99966% of all opportunities to produce some feature of a part are statistically expected to be free of defects. Six Sigma uses a lifecycle called DMAIC, that has five distinct phases each consisting of an array of tools that can be employed - depending on the nature of the project:
A Lean Six Sigma project can be a really effective way of delivering Process Improvement Projects - a distinct methodology from PRINCE2 or PMBOK. Alternatively, if you are managing mainstream project using either of these methodologies, you could then run a LSS Project using DMAIC on the across the Project processes themselves e.g. your demand management process, testing processes etc. What are your experiences of Lean Six Sigma and DMAIC, good and bad? Let us know in the Comments! Stay Healthy! Project Health Check - projecthealthcheck.org Risk Management is one of the well established fundamentals of Project Management. Whatever system or tool you use, the basics of rating risks with some degree of severity and impact is well understood, and then doing something to stop it (because they usually are threats). But I have a challenge for you: look back over your last Project and consider - how many of the issues that occurred along the way were from impacted Risks that were identified on your Risk Log? I predict very few of them. I contend that we are typically very weak at one critical part of Risk Management: Risk Identification. And if you don't identify the potential risk in the first place then there is no way you can manage it - despite any fancy risk processes and tools you may have! This is where we can deploy one very effective process - the Risk Identification Workshop.
The Risk Identification Workshop is carried out during Project Planning, and is essentially a risk brainstorming session to try to identify everything and anything that may impact the Project. It is a proactive exercise to try to identify risk, rather than more typical passive identification mechanisms we see - for example something happens to pop up during estimating or requirements development and is added to the Risk Log. Its purpose isn't to develop detailed descriptions, evaluations or response plans to risks - merely to get first sight of them and get them on the radar. Risk Identification Workshops work best when all key stakeholders are engaged, and can hopefully attend in a face to face session. Established Risk Prompt Lists can be used, which list a variety of key categories of consideration to the Project. This is essentially applying Lessons Learned to the Project, as historically these categories have been identified as having been sources of Project. Workshop attendees then throw out thoughts and ideas against each category in a positive collaborative environment, brainstorming anything that could later manifest as a risk. This works best with the prompts written on a marker board and post-it notes stuck on with ideas. Then the Project Manager or PMO team member can start to scribe them so they can be analysed and evaluated as a later date - not as part of this session. Typical Prompt Lists may include: SWOT A simple classic - what are we good at and succeeded at in the past, what are we bad at and have failed at in the past?
PESTLE This is typically used as Programme or Portfolio level to look at Strategic influences on the future work programme:
Our Project Risk Workshop Template contains these Prompt Lists and others, and allows you to record potential risks identified in your workshops - check it out in our store now! Have you ever used a Risk Identification Workshop in the past, and how did it work for you? Stay Healthy! Project Health Check - projecthealthcheck.org Let's talk Dependencies. A Dependency is a relationship between two activities, and is most often encountered in the Project Schedule. In this case they are used to structure the order of tasks, to help you plan the Project. Logically, there are four type of Dependency relationship - shown in the diagram below:
Lag and Lead time in also a concept in these logical relationship. Lag represents a time delay following task 1 before task 2 initiates, such as waiting for paint to try before fitting the wall lights. Lead is essentially negative lag, for example you could start fitting wall lights on one wall before all of the other walls paint has dried.
We've seen people make the mistake of thinking that by logging Dependencies in the logic of the schedule, that's them covered. But the problem with this is that a big schedule may have thousands of tasks and thousands of dependencies - how do you "see the wood for the trees"? You tend to find that, although there are many Dependencies on a Project, there are only a few key Dependencies. It's not worth making a special effort to track pretty mundane day-to-day dependencies which we take for granted, but these key Dependencies are critical to your Project's success - and so warrant special attention. You can think of these key Dependencies in terms of a "Give-Get" relationship; either you are Giving or you are Getting. Typically it will be a key delivery from a 3rd party or supplier, or a key milestone date you have to deliver something to the client. In this case you should use a Dependencies Log to track them; this will make sure you maintain visibility of them and are able to more easily monitor them. An alternative is to recognise Dependencies as a source of Risk on your Project, which they certainly are; any "Gets" which you are waiting for from outside of the Project are not under your direct control. So you may chose to scan Dependencies to identify Risks that you need to log and manage, or you may actually integrate your Dependency Management into your Risk Management Tool/Process entirely. What experiences do you manage Dependencies on your Project? And if you need a Project Dependency Log Template we have you covered in our template store! Stay Healthy! Project Health Check - projecthealthcheck.org This is a new one for us - Book Reviews! Continued learning and development is important not just for Project Managers, but for practitioners in any field; this development needs to be a combination of new in-the-field experiences, and the theoretical grounding it is based upon. This particular book is the "Project Management Pocketbook", by Keith Posner and Mike Applegarth, and stands out on my Project Management Bookshelf both physically and conceptually.
Physically: my first impressions are that this is a tiny little book, with 110 pages but less than 15x11cm in a landscape-type format- about 1/3 of the height of a normal piece of paper, and 2/3 the width. It's clear this isn't mean to be a Project Management tomb, unlike most of the other books on my shelf. Which is where the conceptual difference comes in: most of my books tend to be the official textbook of various certifications and methods. Frustratingly many of them are now out of date versions! But I think that is one of the positives of this book; it isn't linked to a particular methodology or system, and its basic concepts are timeless. Its clear it doesn't set out to be a definitive end-to-end Project Management book, but instead little hints and tips each one to a small page. I think perhaps this will mean that mean that rather than having yet another book gathering dust on a shelf, you are much more likely to dip in and take 30 seconds to read a page - so you'll more likely get some benefit from it compared to "just another textbook". The Contents breaks the book down into What is a Project, Scoping, Planning, Implementing, Evaluating the Project and also working with People. The last section is especially useful as it moves us away from thinking about the Project Lifecycle and reminds us of our role as a Leader in the Project as well as a manager. The other phases don't correspond directly to any Phase names I've seen in any Project Management methodology, but are universally understandable. As to the content, it's a bit of a random bunch consisting of various simple techniques and ideas - for example SWOT Analysis, PERT Diagrams, Project Reporting etc. Some of the acronyms were new to me such as "the 5 C's of decision making" and "SQUID", but that didn't make them any less useful - actual it was more because it would have been pointless if it was recycling the same old material. All in all, not a bad book - I'm pretty sure I could do better, but who has the time? Let us know your opinions in the comments below. Stay Healthy! Project Health Check - projecthealthcheck.org When you're starting a new project, you of course identify staffing requirements as part of your estimating. You start to "put bums on seats" as you ramp up the project towards the Execution phase and on-board your project team. You hopefully even have a Team Management Plan that describes how you manage the team; how you on-board, train, mentor and recognise staff. You do all of that and think "phew! That's another job done!" But unfortunately that isn't always the case because there may unfortunately be staff turnover during the Project's lifetime.
Staff may come and go during the Project for a number of reasons: sickness, personal issues, reassignment to other priorities by higher mangers or as is often the case, by leaving the company to pursue opportunities elsewhere. Losing staff partway through a project is always tricky as you lose not only the individuals general expertise, but also their specific insider knowledge of your Project, client or technology. This presents a Risk to the Project that you need to mitigate as much as possible, and the best way to do that is via having a robust Knowledge Transfer Process. Knowledge Transfer (KT) is where an Outgoing team member passes what they know to an Incoming team members. It should ideally be supported by a standard Knowledge Transfer Plan Template to ensure consistency of KT - and we will be launching such a template soon so keep an eye out! The KT should then follow a consistent repeatable Process; we outline a 5 Phase Knowledge Transfer Process below which you can use on your Projects: 1. Plan Knowledge Transfer The object of this phase is to produce a comprehensice Knowledge Transfer Plan that will detail precisely what information will be transferred and when, covering all aspects of KT. As we start, there is an assumption that the incoming resource has been identified as is ready to onboard into the organisation - any delay in this reduces the KT window, and increases the risk of the loss of expertise. Using an existing KT Plan Template your organisation should have, the first task is to understand the time constraints that will affect the KT. By understanding when the Outgoing resource leaves, when the Incoming resource can start, and their relative working hours you can then get an appreciation of the size of the KT window. From here, a time analysis should be completed using a "Working Backwards" method to break the time down into the next 3 phases we outline below (KT Sessions, Shadowing, Reverse Shadowing). The KT window may often range anything from 2 weeks to 3 months, but could be outside of these bounds in extreme circumstances. Then, every aspect of the role should be identified and factored into the KT Plan, with sessions for each across the KT Sessions, Shadowing and Reverse Shadowing phases. Many roles include tasks with a degree of periodicity, usually weekly or monthly, such as a weekly status report or attending a monthly programme board. These should be factored into planning give at least one experience of each in the Shadowing and Reverse Shadowing phases if possible. 2. Execute KT Sessions Each discrete area of knowledge identified should have a planned session to review. There should be some sort of documented work instruction, which may potentially be a step-by-step procedure for more transactional work. The session should use this work instruction to define inputs, activity, outputs as well as what tools & assets are used. Here is where more mature organisations win out: if standard processes and tools are defined universally in the organisation then they benefit from this being a lot quicker and easier. But immature organisations, where everything is bespoke and where teams operate in silos, suffer the consequences of this being a lot more time consuming. Be warned! 3. Execute Shadowing So the new resource now knows the basics of the role, now they need to watch it in action to see how it plays out for real. They should shadow the Outgoing resource when they complete these tasks so they can start to understand how the theory is applied. 4. Execute Reverse Shadowing It's now time for the new team member to get hands on and try the work in anger. Only by doing can they really get familiar with the role, and others involved in their activities understand who they are and that they are the point of contact going forward. Be it producing the report or chairing the meeting, they now take the lead. The Outgoing resource is still in the background to shepherd the Incoming resource to make sure errors are identified and corrected, but there involvement should steadily reduce throughout this phase. 5. Complete Knowledge Transfer By the end of the Reverse Shadowing phase, the new staff member should be as well prepared as possible to take on the new role. You should now have a good appreciation on how competent and capable they will be compared to the outgoing resource, but obviously it will still take some time in role before they reach their full potential. Use this final step to identify any specific remaining shortcomings or Risks that you need to be aware of as the new resource moves to independently operate their new role, and Implement risk mitigation actions to try to prevent those shortcomings from impacting the project. Ideally, the outgoing resource will still be available for the occasional query for some time to come just in case, a form of extended Reverse Shadowing-lite; but this can't always be relied on. What have your experiences of Knowledge Transfer been like in Projects? And don't forget to keep an eye out for out KT Plan Template that will be launching soon! Stay Healthy! Project Health Check - projecthealthcheck.org Urgent requests: it seems like most requests we get are. I took over a role recently, and rather than a detailed Knowledge Transfer plan covering many topics over a number of weeks, it basically took half an hour. "Most of what I do is respond to urgent requests". Well then, I thought, there's your problem.
Urgent Requests literally hold us hostage for our time, and we never have any warning they are coming. "The Tyranny of the Urgent" is a phrase that neatly describes this ever present effect, which can not only be detrimental to our Project delivery, but the stress it induces has a detrimental effect on us as human beings And yet the more we react to these unplanned activities, the more we are on the back foot - the more we are reactive. Sometimes called "Context Switching", it has been shown that any shift of attention to a new task ends up costing us a lot of time in trying to re-focus. That gives us less the less to get on the front foot and shape the reality of the projects we work on. It's a downward spiral that you need to fight your way out of fast. But how? First, we need to understand the root cause of these urgent requests. which I broadly categorise into two:
I suggest a five-stage approach to better manage these urgent requests: (1) Do your basic Project Planning right We all know the Project Management textbooks, and often cast them aside once we've passed the relevant exam. But don't, because doing the basics right in any discipline will set you up for success. Do you have a Communications Management Plan, does it reflect reality and has it been widely reviewed and agreed to? This is how you plan your communications, so if someone has an urgent request for information then something must have been missed during communications planning - fix it. But robust planning in general will set up the project for success; things like engaged stakeholders, managed risks and a realistic Performance Measurement Baseline will reduce the likelihood of issues appearing in the first place. Skip these basics and you are only setting yourself up to be on the back foot for the rest of the Project; the Project Manager should dictate how the project will play out, not vice versa. (2) Define an Issue Escalation Process In point 1 we attempted to avoid urgent issues and escalations in the first place by proper planning. If that doesn't work then we need to put in place a process to manage these. This takes these ad-hoc uncontrolled requests that may be coming in from many directions, and funnels them into a standard process where we can impose order upon them. Define escalation routes for different types of issues e.g technical, financial etc. You can use a Communications Plan or an Issue Management Plan for this; but make sure you define it somewhere and then communicate it effectively - be it via email, apresentation or even desktop tri-folds. (3) Reduce your exposure In step 2 we defined an escalation process, in step 3 we make sure it is adhered to. Despite best intentions, it can be easy in the pressure of the moment for individuals to skip the defined escalation routes - especially if they can see you right there. There are times you need to reduce your exposure to these rogue escalations by physically or digitally making yourself unavailable. Work remotely if you need to complete an isolated major task (e.g. writing a key part of the plan), mark yourself as busy or do not disturb on instant messenger tools, hot desk in different parts of the office such as empty meeting rooms. It can feel like you are avoiding responsibility, but in reality most problems can be resolved without your interaction. So while you do still need to be reachable in some way for appropriate escalations, this will free you up to focus on running the Project properly. (4) Delegate Now and again a urgent request will rightfully come your way, perhaps a customer escalation for example. But this still doesn't mean you need to drop what you are doing to personally resolve it; you are Accountable for making sure it is resolved, not necessarily Responsible (think RACI). A Project Manager is a leader, so use your team by delegating and overseeing this request to the most relevant staff member, or to the staff member who has availabilty or isn't on the critical path at the moment. (5) Learn So a genuine urgent request came you way, and you managed to resolve it - good. Now try to learn from this: understand the root cause of this urgent request and take Preventative Action to stop it happening again, otherwise you are doomed to repeat it. Was it an urgent request for some project status information from higher management? Then look to see if you can include them on the distribution of status reports you already produce, or alternatively understand what information they need that you don't already produce - then amend the Status Report to capture this. Ask yourself the question "how should have this been taken care of by our normally processes such that this urgent request never happened?" - try to make sure this is the last time you will get an urgent request of this nature. But while you are doing this, think Lean - avoid adding more unplanned work by reusing exist activities as much as possible. Let us know in the comments below how many urgent requests you get on your Projects, and how you handle them. And check out our articles on Project Lessons Learned and our Lessons Learned Log Template if you want to effectively implement point (5) above. Stay Healthy! Project Health Check - projecthealthcheck.org |
Mission:To understand why do Projects Fail and what we need to do differently to stop it happening again. Archives
March 2018
Categories
All
|