5 Reasons to Kill IT Projects
A survey of IT experts revealed 43 percent of their organisations had recently killed an IT project. The study, conducted by ISACA, an independent IT governance group, highlighted the top 5 reasons these organisations named for terminating projects prior to completion.
Here’s the list, with my commentary on each issue:
1. Business needs changed: 30%
There are many conditions and situations where a business legitimately changes its requirements after starting a project. If the project no longer provides meaningful value, then it’s best to stop throwing good money after bad.
The best 5 Project Management Tools
Definitions for common tools used when planning a project.
Gantt Chart
A Gantt chart is a popular type of bar chart that aims to show the timing of tasks or activities as they occur over time. Although the Gantt chart did not initially indicate the relationships between activities this has become more common in current usage as both timing and interdependencies between tasks can be identified.
Since the initial introduction of Gantt charts, they have become an industry standard as a key project management tool for representing the phases, tasks and activities that are scheduled as part of a project Work Breakdown Structure or time-line of activities.
Continue reading »
In Defence of the Project Management “Perfect World”
By Carl Pritchard, PMP, EVP
One of the most common challenge questions I get when teaching PMP® Exam Preparation courses is “Why doesn’t PMI® make the test more real-world? Why do they insist on testing for a world that no-one really lives in?” Over the years, my response to that question has evolved, but the more the question comes along, the more I realise we don’t insist on the perfect world often enough.
At different times in history, there must have been push-back on any variety of steps forward in human progress. Some folks found the notion of indoor plumbing repulsive. (You’d actually do that? In your house?) Seat belts were seen as clothes-rumpling traps that might pin us in the car in an accident. Thomas Watson, when president of IBM, said, “I think there’s a world market for about five computers.”
We look at a different world, a future, perfect world, because it is where the promise is. Science fiction is a popular genre in movies and books because it opens the eyes to what is possible. Since I was in my teens (quite a few years back), I’ve seen movies featuring flying cars. Do we have them? No. Do I hope we do some day? Sure! Is there some scientist somewhere trying to make it happen? I certainly hope so. We step into the future thanks to people who envision the world as it could be.
On the project management certification exam, many of the questions focus on an understanding of the world as it should be in project management. A few examples:
- Senior management writes and signs chartering documents.
- Procurement departments deliver what we ask for in a timely fashion and help us craft better contracts.
- Human Resources departments provide skilled resources on demand with the properly qualified skill sets.
- Management understands that range estimates are more honest and realistic than single-data-point estimates.
Is this the world as it is? In most organisations, no. And yet, if you hope to pass the premier certification in project management, this is where you need to be. Does that make the exam wrong? No! In fact, it means that the professional association of project managers recognises that there is, out there, as Ronald Reagan put it, “a shining city on a hill.” There is an ideal. There is a standard to which we should try to hold our organisations. There can be better and more effective project management if we are willing to acknowledge that business as usual is not business as it should be.
Suppose the certification exam’s “perfect world” started becoming reality. The changes in the project management environment would be dramatic.
- Every project would have a clear business case and a defined priority within the organisation.
- Resources would be respected when they provide estimates, rather than forced to create padded estimates that hide reality.
- Risk contingency budgets would be overt, with clear tracking systems for when they’re drawn down upon.
- There would be a consistent moment in time when project managers would answer Microsoft Project’s “save with a baseline?” question in the affirmative.
In the June 4, 2008 Washington Post, the front page of the newspaper included an article by Dana Hedgpeth about Lockheed Martin and the Project on Government Oversight (POGO). POGO had unearthed a Defence Contract Management Agency report that cited the huge defence contractor for failing to track and manage their projects properly. The article specifically called out failings in earned value management systems.
Lockheed got the attention because of the leviathan proportions of their contracts with the government. But how many smaller, leaner organisations are guilty of the same shortcomings? The argument is made that earned value and other rigid, rigorous processes of project management are too weighty. It’s suggested that they’re not worth the return. I doubt very much that Lockheed would agree right now. Rework is almost invariably more expensive than doing it right the first time.
Which brings us back around to PMI®, the certification, and the perfect world. What good is a certification that says that every process needs to be followed every time in a consistent fashion? It sounds very good to me. And it also provides a jumping-off point to take steps toward that perfect world. As more and more organisations demand certifications, they afford the perfect response to management seeking to shortcut process.
- Management: Stop bothering the client with all of those change orders for little stuff. We’re building goodwill here!
- Certified manager: It’s part of best-practice process.
- Management: It’s not best practice if it costs us a client!
- Certified manager: If everyone is consistent, it won’t.
- Management: But everyone’s not consistent.
- Certified manager: You’re telling them all to get certified to make them consistent. And the certification exam says we do this consistently, with the paperwork.
Granted, too many conversations like that and you wind up working on your resume, but…
The point is that we need to acknowledge that PMI® and the other certifying bodies are working toward an environment where we have consistent best practice. They have to test to the ideal, or else the ideal will never be achieved. In working on the team to generate the fourth edition of the Guide to the Project Management Body of Knowledge, I was occasionally surprised to hear arguments about real-world versus perfect-world project management within that group. As an ANSI standard, that book needs to reflect the ideal environment for project success. And that’s an environment we should all strive to embrace.
Distinguishing Portfolio Management, Programme Management and Project Management
By John Reiling
There is often a misunderstanding, and hence a mixed and overlapping use of terms, when it comes to programme management. Sometimes a programme is called a project. Sometimes a project is called a programme. In addition, sometimes project portfolio and programme are mistakenly used interchangeably. This article is intended to clarify the main differences and to distinguish the unique aspects of project portfolios, programmes, and projects.
A great way to start to think about these is to think in terms of a pyramid hierarchy. At the top of the pyramid is portfolio management, which contains all of the projects and programmes that are prioritised by business objectives. Below that is programme management, which contains numerous projects that are interrelated, since they support a particular business objective. Programmes consist of multiple projects, but projects can be independent and simply part of the portfolio. Projects differ from programmes in that they are strictly tactical in nature.
Here is a more detailed look at each:
Portfolio Management
One of the key distinguishing features about Project Portfolio Management is that it is a process that is clearly characterised by business leadership alignment. Priorities are set through an appropriate value optimisation process for the organisation. Risk and reward are considered and balanced, and programmes are selected based on their alignment with organisational strategy. Feedback is provided from programme and project implementation so that portfolio adjustment can occur, if necessary. Strategic changes can also require portfolio adjustments.
Programme Management
A key distinguishing feature of Programme Management is business sponsorship. Almost by definition, based on decisions made at the Portfolio Management level, programmes are sponsored by business needs. The programme takes on the ownership of benefits and is measured primarily based upon achievement of those benefits. Programmes can also sometimes have “benefits streams,” or sets of interrelated benefits, such as increased R&D capabilities combined with increased market penetration, that cut across functions in the organisation. Because programmes, naturally consisting of multiple projects, span functions within an organisation, they have all elements of a business system, and hence are general management oriented.
Project Management
Project Management is most concerned with delivery of capabilities, typically as defined within a programme. Projects need to be strategy-driven, but do not own the strategic initiative as does a programme. Rather, the project takes inputs and develops and implements a tactical plan. Monitoring along the way and final measurement of success is typically based more on the tactical considerations such as budget and schedule than upon achievement of a strategic business objective.
Now, with the basic distinctions among Project Portfolio Management, Programme Management, and Project Management defined, each organisation must “personalise” its implementation of these three processes. Some key factors and how they affect choices made about implementing each are as follows:
- Industry: Industry provides insights into the stability and consistency of operations. Some industries, like pharmaceuticals, are be very driven by product lifecycles, albeit fairly long ones that include a major regulatory process. Consumer electronics companies are driven by much shorter project lifecycles and rapidly evolving technology, with little regulation. Construction firms are highly porjectized and deal with very stable technologies and products.
- Organisation Size: Generally, greater size requires more formal organisation. Without structure, the relationships between strategy, portfolio management, programmes, and projects can become blurred and disjointed. The two points of focus here are to have well-considered organisational frameworks for each of portfolio, programme, and project management, and then to pay special attention to building strong ties among them for communication, collaboration, and information flow.
- Operational Breadth: A more narrowly defined operational capability, such as found in a sales-focused or production focused organisation, will tend to require less formality, and information will flow more freely among portfolio, programme, and project management processes. In organisations that are well-integrated horizontally, containing well-developed core competencies in R&D, marketing, production, distribution, and the like, there will be natural separations that need to be managed. This will make programme management especially challenging, since it is likely to cross those boundaries.
- Strategy: Like the various operational considerations, the strategy will effect organisation of portfolio, programme, and project management based on how complex it is. One key consideration not mentioned above is strategic alliances, which can greatly effect how tightly managed and how structured these processes need to be.
Standards for Project Portfolio Management, Programme Management, and Project Management do exist, and clear definitions can be found within. The worldwide Project Management Institute (PMI) has developed and published the following standards (free for members):
- The Standard for Portfolio Management
- The Standard for Programme Management
- A Guide to the Project Management Body of Knowledge (PMBOK Guide) Third Edition
10 Golden Rules of Project Risk Management
The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner. The result will be that you minimise the impact of project threats and seize the opportunities that occur. This allows you to deliver your project on time, on budget and with the quality results your project sponsor demands. Also your team members will be much happier if they do not enter a “fire fighting” mode needed to repair the failures that could have been prevented.
This article gives you the 10 golden rules to apply risk management successfully in your project. They are based on personal experiences of the author who has been involved in projects for over 15 years. Also the big pile of literature available on the subject has been condensed in this article.
Rule 1: Make Risk Management Part of Your Project
The first rule is essential to the success of project risk management. If you don’t truly embed risk management in your project, you can not reap the full benefits of this approach. You can encounter a number of faulty approaches in companies. Some projects use no approach whatsoever to risk management. They are either ignorant, running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). Some people blindly trust the project manager, especially if he (usually it is a man) looks like a battered army veteran who has been in the trenches for the last two decades. Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff.
Rule 2: Identify Risks Early in Your Project
The first step in project risk management is to identify the risks that are present in your project. This requires an open mind set that focuses on future scenarios that may occur. Two main sources exist to identify risks, people and paper. People are your team members that each bring along their personal experiences and expertise. Other people to talk to are experts outside your project that have a track record with the type of project or work you are facing. They can reveal some booby traps you will encounter or some golden opportunities that may not have crossed your mind. Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. Paper is a different story. Projects tend to generate a significant number of (electronic) documents that contain project risks. They may not always have that name, but someone who reads carefully (between the lines) will find them. The project plan, business case and resource planning are good starters. Another categories are old project plans, your company Intranet and specialised websites.
Are you able to identify all project risks before they occur? Probably not. However if you combine a number of different identification methods, you are likely to find the large majority. If you deal with them properly, you have enough time left for the unexpected risks that take place.
Rule 3: Communicate About Risks
Failed projects show that project managers in such projects were frequently unaware of the big hammer that was about to hit them. The frightening finding was that frequently someone of the project organisation actually did see that hammer, but didn’t inform the project manager of its existence. If you don’t want this to happen in your project, you better pay attention to risk communication.
A good approach is to consistently include risk communication in the tasks you carry out. If you have a team meeting, make project risks part of the default agenda (and not the final item on the list!). This shows risks are important to the project manager and gives team members a “natural moment” to discuss them and report new ones.
Another important line of communication is that of the project manager and project sponsor or principal. Focus your communication efforts on the big risks here and make sure you don’t surprise the boss or the customer! Also take care that the sponsor makes decisions on the top risks, because usually some of them exceed the mandate of the project manager.
Rule 4: Consider Both Threats and Opportunities
Project risks have a negative connotation: they are the “bad guys” that can harm your project. However modern risk approaches also focus on positive risks, the project opportunities. These are the uncertain events that beneficial to your project and organisation. These “good guys” make your project faster, better and more profitable.
Unfortunately, lots of project teams struggle to cross the finish line, being overloaded with work that needs to be done quickly. This creates project dynamics where only negative risks matter (if the team considers any risks at all). Make sure you create some time to deal with the opportunities in your project, even if it is only half an hour. Chances are that you see a couple of opportunities with a high pay-off that don’t require a big investment in time or resources.
Rule 5: Clarify Ownership Issues
Some project managers think they are done once they have created a list with risks. However this is only a starting point. The next step is to make clear who is responsible for what risk! Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign a risk owner for each risk that you have found. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. The effects are really positive. At first people usually feel uncomfortable that they are actually responsible for certain risks, but as time passes they will act and carry out tasks to decrease threats and enhance opportunities.
Ownership also exists on another level. If a project threat occurs, someone has to pay the bill. This sounds logical, but it is an issue you have to address before a risk occurs. Especially if different business units, departments and suppliers are involved in your project, it becomes important who bears the consequences and has to empty his wallet. An important side effect of clarifying the ownership of risk effects, is that line managers start to pay attention to a project, especially when a lot of money is at stake. The ownership issue is equally important with project opportunities. Fights over (unexpected) revenues can become a long-term pastime of management.
Rule 6: Prioritise Risks
A project manager once told me “I treat all risks equally.” This makes project life really simple. However, it doesn’t deliver the best results possible. Some risks have a higher impact than others. Therefore, you better spend your time on the risks that can cause the biggest losses and gains. Check if you have any showstoppers in your project that could derail your project. If so, these are your number 1 priority. The other risks can be prioritised on gut feeling or, more objectively, on a set of criteria. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. Whatever prioritisation measure you use, use it consistently and focus on the big risks.
Rule 7: Analyse Risks
Understanding the nature of a risk is a precondition for a good response. Therefore take some time to have a closer look at individual risks and don’t jump to conclusions without knowing what a risk is about.
Risk analysis occurs at different levels. If you want to understand a risk at an individual level it is most fruitful to think about the effects that it has and the causes that can make it happen. Looking at the effects, you can describe what effects take place immediately after a risk occurs and what effects happen as a result of the primary effects or because time elapses. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs, lead time or product quality. Another angle to look at risks, is to focus on the events that precede a risk occurrence, the risk causes. List the different causes and the circumstances that decrease or increase the likelihood.
Another level of risk analysis is investigate the entire project. Each project manager needs to answer the usual questions about the total budget needed or the date the project will finish. If you take risks into account, you can do a simulation to show your project sponsor how likely it is that you finish on a given date or within a certain time frame. A similar exercise can be done for project costs.
The information you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimise the risks.
Rule 8: Plan and Implement Risk Responses
Implementing a risk response is the activity that actually adds value to your project. You prevent a threat occurring or minimise negative effects. Execution is key here. The other rules have helped you to map, prioritise and understand risks. This will help you to make a sound risk response plan that focuses on the big wins.
If you deal with threats you basically have three options, risk avoidance, risk minimisation and risk acceptance. Avoiding risks means you organise your project in such a way that you don’t encounter a risk anymore. This could mean changing supplier or adopting a different technology or, if you deal with a fatal risk, terminating a project. Spending more money on a doomed project is a bad investment.
The biggest category of responses are the ones to minimise risks. You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. A final response is to accept a risk. This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult, time consuming or relatively expensive. Just make sure that it is a conscious choice to accept a certain risk.
Responses for risk opportunities are the reverse of the ones for threats. They will focus on seeking risks, maximising them or ignoring them (if opportunities prove to be too small).
Rule 9: Register Project Risks
This rule is about bookkeeping (however don’t stop reading). Maintaining a risk log enables you to view progress and make sure that you won’t forget a risk or two. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3).
A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). Most project managers aren’t really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off, especially if the number of risks is large. Some project managers don’t want to record risks, because they feel this makes it easier to blame them in case things go wrong. However the reverse is true. If you record project risks and the effective responses you have implemented, you create a track record that no one can deny. Even if a risk happens that derails the project. Doing projects is taking risks.
Rule 10: Track Risks and Associated Tasks
The risk register you have created as a result of rule 9, will help you to track risks and their associated tasks. Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks or to generate, select and implement responses.
Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which risks are more likely to happen? Has the relative importance of risks changed? Answering this questions will help to pay attention to the risks that matter most for your project value.
The 10 golden risk rules above give you guidelines on how to implement risk management successfully in your project. However, keep in mind that you can always improve. Therefore rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your risk management efforts and continuously implement improvements to make it even better.
Success with your project!
By Bart Jutte
Strategies for Managing Change: The Project Manager
The title of project manager (PM) is used to mean different things in different companies. Fortunately there is a standards body called the Project Management Institute which provides excellent guidance around the role and function of a project manager.
Some will disagree, but I don’t care if your project manager is PMI certified or not. You need to care about having a project manager with the skill to carry out the role as the Institute defines it. It’s your change management strategy, and it’s your reputation on the line.
Finding a Project Manager
Do you need a certified Project Management Professional (PMP)? As I said above, I don’t care. There are newly certified PMP’s who have taken their tests and gotten the certification, but they may not be battle tested. There are veteran project managers who never got the fancy title, but they know how to manage projects. And there is everything in between. The track record is what you need to care about.
Do you have a strong PM on your team now? Is that person well respected, perhaps a key opinion leader in your organisation? Do they treat project management as a profession? Then by all means use them.
If, on the other hand, project manager has been a title used by junior, untrained people who walk around with a task list and a clipboard, it’s time to bring on stronger talent.
Your fastest route to a proven project manager will be a contract hire, either from a reputable firm or an independent. There are many good ones out there. Get and check references, and interview at least three. Let your key opinion leaders and managers interview them as well. Look for their track record and for good chemistry.
Set the Project Manager Up for Success
Simply put, everyone needs to understand that the project manager is your alter ego. Everyone includes you.
Your managers and project leaders must understand that they are accountable to the PM for providing all of their tasks, their dependencies on other tasks and other work units, their schedule commitments, and their resource requirements.
They need to understand that the PM will review all of their information and look for problems. These could include missed tasks, schedule inconsistencies, resource overloads, etc. Often managers will tell the PM that they can handle some of these problems, by working people longer hours or by overlapping some tasks “by a day or two.” A good project manager is going to challenge such claims, and you’ll need to stand behind the PM.
The PM is going to hold everyone accountable for milestone deliverables. In most projects, especially those that are complex, milestones are missed and contingency plans must be activated. Again, you as the leader need to support the PM as they hold people accountable.
Handling Conflicts
It’s entirely possible that the PM will have conflicts with managers, team leads or others in the organization. Make it safe for people to discuss and bring up such conflicts. Just because the PM is your alter ego doesn’t make them right, any more than you are always right.
Engage your key opinion leaders along with the project manager and others. Find out the facts contributing to the conflict, and make the decisions necessary to get the change management strategy back on track.
Change management strategies that fail often do so because of poor project management. Don’t let that happen to you.
