Do it right or do it fast?  There's sometimes a price to pay for "Do it fast". It's called Technical Debt.

Probably the most famous example of technical debt is MS-DOS. Back in 1981, IBM asked Bill Gates for an operating system for its new PC. To deliver on time, he took QDOS, (QDOS stood for Quick and Dirty Operating System) and renamed it MS-DOS. Born quick and dirty, MS-DOS was loaded down with debt from its very conception, with a poor command set and limited features.

In the world of project management, on time delivery is a key measure of project success for most projects. As you rush to meet the deadlines, you may be accumulating debt silently, invisibly... but incessantly.

Technical Debt may appear as

o   No documentation or user guides

o   Low quality programming (unstructured, few comments, hard-coding)

o   Badly structured databases (redundant data, data errors)

o   Poor designs (poor architecture, not modular)  

o   Poor processes (inefficient, waste time, error prone)

Debt is typically associated with software projects, but it's not only about software - all sorts of project can generate debt.

Technical debt is often generated by the pressure to finish on time, but it's not just a question of speed. There are several sources of debt.

• Speed: rushing is probably the number one cause of technical debt.
• Short term view: Patching and mending. Non-architected solutions
• Fire-fighting: Focusing on backlog (not on the future)
• "Bleeding-edge" innovation: Learning as you go along
• Lack of skills: Putting staff with wrong skills (or no skills) onto complex tasks 

Why do we worry about it?

Technical debt is like financial debt... you can ignore it for a while, but the accumulation of debt will come back and haunt you.  As you build up debt, you end up with a mess - a patchwork or spaghetti that's difficult to understand or difficult to change.

That's a potential surcharge on everything you try to do - technical debt can slow down and complicate future projects. You may also end up with premature aging - the accumulation of debt can shorten the lifetime of your solution.

Don't Sprint into debt.

The main cause of debt is speed. Some project management methods focus on speed, notably most lightweight variants of Agile. Lightweight Agile methods such as Scrum can force you into debt if you over-focus on sprints and speed. You may deliver on time, but if you sacrifice other factors of best practice, such as design, planning or quality, then you could be accumulating debt.

There are two ways around this problem for Agile projects. You can try to make your lightweight method more robust (as described in the book "Managing Software Debt" by Chris Sterling) or you can use an enterprise Agile solution

How Enterprise Agile helps

Enterprise Agile methods such as DSDM Atern (sometimes branded as AgilePM) allow you to combine agility with architecture and design. Atern also has a project management toolkit to ensure a long-term approach (plans, business case, etc.) - these help to clarify the trade-off between speed and debt (and therefore to remove or reduce debt).

Whichever way you choose, and whether you use Agile or not, you need to be aware of debt. You probably won't be able to be debt free, but you should apply three golden rules:  

• Start today to pay back old debts (each new project cleans up some previous mistakes and clutter)
• Avoid new debt (do it right in future, balance speed with quality)
•  If a project does have to sprint into debt, clean up the mess ASAP

Need to deliver on time? Then start using time-boxes!

On time delivery is the El Dorado of project management. No one wants to be late for a key deadline. As the deadline approaches, and you’re running late, the project manager and the project team work like crazy to stay on time.  Everyone works late and comes in at weekends. This generates stress, overload, even burnout.

There’s a better way to deliver on time. It’s called time-boxing.

What is a time-box? A time-box has an fixed end date, which is fixed, but the work to be done is variable. If you are running late, you have a clear, pre-approved way of doing less. If you have less to do, you can probably get back on schedule. Before the time-box starts, you need to list the work to be done, and then get agreement on how prioritise it.

Here’s an example, for a simple project to tidy up and repaint a garage.

Without a time-box, you might list the needs in any order, perhaps in order of work
    •    Sort content of boxes
    •    Recycle junk
    •    Install new lighting
    •    Buy new tools
    •    Paint floor
    •    Paint walls & ceiling
    •    Paint woodwork

Without a time-box, if you run short of time, you may have to rush the last painting tasks. If you want to do a good job, you’ll be painting until midnight, and completely stressed out…

By using a time-box, you can keep calm and avoid panic. You will focus on the essentials, and make sure that those essentials are delivered on time.

The trick is, before you start work, you should get the time-box agreed. You need to prioritise the list of needs.

Prioritised list
     -- Must have --
    •    Paint walls & ceiling
    •    Paint woodwork
    •    Recycle junk
    -- Should have --
    •    Paint floor
    •    Install new lighting
    -- Could have --
    •    Sort content of boxes
    •    Buy new tools

 If we are a bit late, we will drop one or more items from the “could have” list. If we are seriously behind schedule, all the “could have” items and one or more “should have” items won’t get done. We will plan our work accordingly, with the the “must have” items early in the schedule and the “could have” items later.

The first time you use time-boxing, you might hit the problem that people can’t or won”t prioritise their needs. Your boss might say that everything is top priority. Nothing is negotiable. That’s normally not true, especially if on-time delivery is important. You may need to “educate” your boss. You may need to help people think through the real priorities.

If you are using a method like Prince2, you can add time-boxing to your work. In Prince2 terms, a stage or a work-package could be a time-box. You commit to deliver on time (zero tolerance on time), but you have a lot of flexibility on what you delivery, using your prioritised list of needs (so you have high  tolerance on scope)

Another choice for methods is to move to an Agile method such as Agile ATERN (with AgilePM certification), which is built around time-boxes and prioritised lists. This method  uses the acronym MuSCoW for Must have, Should Have, Could Have, Won’t Have to help you remember to prioritise.

So if you are always rushing to hit your deadlines, you have a better way forward. You have a way to avoid last minute stress and panic. If need to deliver on time, then it’s time to to start using time-boxes.

Project management, change management are like apples and pears

Should a project manager be a change manager? The traditional answer was YES, a project manager should know how to manage change. Today the answer is more often NO, as there are new and better ways to manage change.

Change initiatives are increasingly using a new role of Business Change Manager to manage complex change. In such cases, the project manager is no longer a change manager. Apples are apples and pears are pears: project managers manage projects. And change managers manage change.

What is wrong with a project manager running change management? Why invent this new role of Business Change Manager?

If we understand the Customer - Supplier relationship in projects, we will understand why. A Customer - Supplier relationship underpins most change initiatives: the project teams are on the supplier side, delivering a solution. The business teams are on the customer side, using the solution.

This “customer - supplier” relationship is not a question of contracts or invoicing. This relationship exists even for internal project teams working inside one company - an internal supplier provides a solution to an internal customer

This is why the we have two distinct roles, the project manager role and change manager role. One role on the supplier side, a separate, distinct role on the customer side.  And this is a peer-to-peer relationship, where the two roles are equal, not hierarchical.

Programme management methods like MSP (Managing Successful Programmes) recognise this separation. MSP has two two key processes
    ❑    a supply side process, called “Delivering the Capability”, for building the solution in project mode 
    ❑    a change management process on the customer side, called “Realising the Benefits”, for transitioning to the new solution and measuring the success of the change.

This approach has many advantages. Notably, it recognises that the motivations of the Project Manager and the Business Change Manager are very different.

The Project Manager is often motivated by
    ❑    technology (performance, features, innovation)
    ❑    sign-off and approval
    ❑    project performance measures such as finishing OTOB (On-time and On-budget)
   
The Business Change Manager has different concerns
    ❑    reliability, stability
    ❑    ease of use, training, support
    ❑    good documentation
    ❑    long term benefits

The Business Change Manager role needs business skill, rather than project management skills. The Business Change Manager should be chosen from the business area that will use the new solution. Crucially, after the solution is implemented, the Business Change Manager will return to the day-to-day business, and will use the solution week-by-week, month-by-month.

This reveals another important difference in motivation between the two roles the Business Change Manager (and his or her colleagues) is going to use the new solution, whereas the Project Manager will probably never do so. That’s a big difference, and that’s another reason why we we need a dedicated Change Manager.

So for your next business change initiative, try not to mix apples and pears. Don’t confuse project teams (apples) and business teams (pears). Project managers should manage projects. And change managers should manage change. Keep those apples and pears apart.

Time for timesheets.. or wait until tomorrow?

If you want to get control of your projects, you should use timesheets. Or should you? Is the accepted wisdom really wise?

Timesheets allow you to measure effort; i.e. man-days of work. All project management methods suggest you should control time and cost. Human effort one dimension of cost. It is normally expressed in man-hours or man-days of work (which usually can be  converted into a financial cost). To control effort, you need to estimate it when you plan and then track the actual effort. That’s where timesheets come in, to track the actual effort.

The Prince2 project management method follows this approach. The Prince2 planning process has an estimating step. For Prince2, effort is the primary resource estimation for each task. (Secondary resource needs include equipment, travel or money). By saying that you should control effort, Prince2 ask you to plan and then to track effort. Prince2 therefore assumes that you will use timesheets.

That’s what they are doing at one major bank using Prince2. Effort is indeed the main measure of project resource estimation. A small banking project may have a budget of 50 man-days of effort, whereas a large project may have a budget of 3000 man-days. To monitor progress, the bank uses timesheets to record actual effort by the project teams. So, for example, a 10-week project estimated at 50 days may finish with 45 (or 55 or whatever) actual days of effort. This is calculated from the timesheets of all the project team members submitted during the 10 weeks.

So timesheet solutions aggregate a lot of data from a lot of people. You need timesheet software, which lots of people need to use correctly and regularly. That’s where the problem starts. The software vendors will tell you that the software is easy to use (maybe true, maybe not!), but they won’t always tell you how much work is needed to achieve a sustained, widely-used solution which truly delivers benefits to your wider organization.

In some organisations, there can be hundreds of people working on various projects. A large hospital tried to implement a timesheet solution to control project effort.  Inside the IT department of about 50 people, this worked OK.  But most projects go beyond IT. The hospital has about 3000 staff, very many of whom could work on a project. You can’t ask 3000 people to fill in timesheets, just because some of them may work on a project from time to time.

Even for the small IT department, the hospital hit another problem, of scope creep. Once they had estimates of project effort for their teams, they had a partial forecast everyone’s future work plans. So they decided to go for a 100% solution, and complete the picture with plans on non-working time (holidays, etc.) and non-project work (support, maintenance, staff meetings, etc.). Once you try to manage the full working week for your entire team, you add extra complexity for little benefit. The hospital could not sustain the effort, and the timesheet solution failed.

There are a lot of failures with timesheet implementations. It’s hard work and there can be a lot of resistance. People don’t like filling in timesheets. It takes a lot of work to get everyone to submit a time sheet each week (and to sustain this 52 weeks per year). Furthermore, if you succeed, the data quality may be low, and consequently the benefits for project control may be slim.

Timesheets can work well in certain environments, for example where hours are billed to the customer. Or in closed environments, such as software development teams, where all projects are done by a limited number of project team members. In these cases, there is a clear benefit to the organization, so you can more easily succeed with timesheets.

If you choose not to implement timesheets, what can you do? One major chemicals company has decided not to use timesheets today for their projects. They know it’s premature – timesheets wouldn’t work today. Their solution is to track cost and time, but not effort.  Costs are tracked (expenditures); time is tracked (activity start and finish dates); but effort is neither estimated nor tracked.

So should you use timesheets? If your goal is to improve your team’s or your company’s project management maturity, yes, it should be on your long term agenda. Should it be a priority? You need to analyse timesheet deployment as a long term project. It’s not a quick-win software implementation project – you need sustained long-term commitment to get any benefits. Work out the business case, study the risks of failure.

You’ll possibly find that deploying timesheets is not a priority project. Your return on investment is perhaps too uncertain, your risk too high. Focus instead today on easier project management improvements with more certain benefits. Wait a while until you tackle timesheets. Mañana, demain, morgen, tomorrow.

Can you measure your project performance?

The Dutch say “Meten is Weten” – to measure is to know. Measurements have become fashionable everywhere. In companies, in schools, in hospitals … everything is driven by targets and measurements. Everyone is trying to deliver their targets and key performance indicators (KPI’s).

The fashion has come to the world of Project Management. However, in Project Management, targets are used slightly differently. Rather than set an arbitrary target, you create a plan. To measure, you compare your plan against reality (your “actuals”). Project performance measures how well you are delivering against your plan.

The traditional performance measurements for projects have always been cost and time. There’s even an acronym OTOB which neatly sums up the Project Manager’s drive to deliver on time, on budget. When people speak about project performance, they typically are talking about OTOB: are you delivering on time, on budget, relative to your original agreed plan?

If OTOB is the traditional measurement of Project Performance, modern Project methods have followed the fashion, and added more measurements. Some people have added a third dimension, Quality, and transformed OTOB into OTOBOQ.

The latest Prince2 manual (2009) follows the fashion. The subject of measurements arrives in Chapter 1, which introduces 6 key aspects of performance (whereas in the previous version it was buried in a later chapter). Prince2 suggests that the best practice is to control not just Time and Cost, but also Scope, Quality, Risk and Benefits.

In reality, you may need to go a little further: you may need to break Cost into Financial cost and Effort, as these must be controlled very differently. Financial cost is based on expenditure of money (purchase orders, invoices…), while Effort is man-days of work. So you have up to 7 aspects of performance to control. For each, you need to compare plan versus actuals

❑ Time
Time is the easiest measurement. Your plan is probably a schedule of work (typically a Gantt diagram), including milestones (and for Prince2, stage boundaries). So this plan gives your planned time. As the work advances, you track actual time using the dates that the work was actually finished.

❑ Financial Cost
Financial cost data is also quite easy to measure. You can estimate your planned costs in various ways. Some people estimate from the Gantt diagram; others collate the information in a Business Case. You should measure actual costs as soon as you commit to expenditure (e.g. when you raise a purchase order). Be proactive about recording actual costs: don’t wait until the invoices are recorded in your accounting system, and certainly don’t wait until they are paid. 

❑ Effort
Effort is mandays of work. Effort can be easy to estimate, but is often difficult to measure. Using a Gantt diagram, you can estimate effort in man-hours or man-days. This gives your planned effort. Effort is difficult to measure, because most organisations don’t have time-sheet systems (or if they have them, they are not used by all project contributors). And, as it’s surprisingly difficult to deploy time sheets solutions (i.e. to get enough people to use them week by week), measuring actual effort is also surprisingly difficult. (For many projects, it’s effectively impossible).

❑ Scope
Scope used to be hard to control, but with modern methods, it’s a lot easier. If you use Prince2’s product based planning, you can predict your planned scope based on the product decomposition. It’s easy to detect when the products are delivered, so you can easily track actual scope. (It’s not just Prince2 that helps. Some Agile methods, such as Agile Atern, also are making control of scope easier: Atern uses a Prioritised Requirements List).

❑ Quality
Prince2 also makes it easier to control quality. Using Prince2’s product based planning technique, you can do simple-but-effective quality planning, giving your planned quality. As the work is done, each planned quality test is done, which gives your actual quality.

❑ Risk
Risk is typically controlled though regular estimates throughout the project, rather than by measurements. Each time you plan (or replan), it’s wise to perform a risk analysis. This gives your forecast of risk – your planned risk. When you execute your risk counter-measures, you mitigate the risk, and lower your forecast risk level. To measure your actual risk is difficult, and probably impossible. The best you can do is to revise your estimates, using regular risk analyses.

❑ Benefits
Benefits are also typically controlled through regular estimates, rather than measurements. In many projects, you cannot measure the benefits, as they are realised after the project has closed. Your Business Case should give the planned benefits. If you can’t measure actual benefits, you should review estimates regularly: using Prince2, you will review your Business Case at the end of each stage (and the associated Benefits Review Plan).

So for Project Managers, “Meten is Weten” (to measure is to know) is a little simplistic. You need to control project performance, but you can’t measure everything.

Certainly Prince2 helps you to "know" your project -  it gives you a framework for controlling your performance – and that helps with boosting your  performance. Give it a try!

Open the gate to more effective project management

For a team manager, one of the simplest and most effective ways to structure your team’s project management effort is to introduce gate-process methods. They are not rocket science, they are not state-of-the-art, but they work. If are manage a group of projects, and you want long-lasting improvements  in project management, then you should be looking at  gate-process methods. 

Gate process methods break a project into stages and gates:
    •    A stage is a block of work in a project (sometimes called a phase). It’s run by the project manager, and typically will be several weeks long, sometimes several months long.
    •    A gate is a decision point. The board makes a go / no-go decision, based on the work done in the current stage, the plan for the next stage and the overall viability of the project. It’s called a gate for a reason: if no-one opens it,  then it stays shut. That’s important. If the board don’t take a explicit decision to proceed, then the gate stays shut and no more resources should be used on the project. The project must stop.

Many best practice project management methods are gate processes. For example, Prince2 is built around stages, but Prince2 is flexible - it  allows for a variable number of stages. Prince2 doesn’t use the word “gate”, but it has end-of-stage decision points which are gates -  the project board must explicitly approved the next stage plan. Gated methods also are a part of best practice portfolio management guidance. In the same family as Prince2, the MoP guide (Management of Portfolios) highlights the importance of gated methods, saying that “quick wins can demonstrate the value of a portfolio management approach. The first steps commonly include applying staged release of funding so that investment of resources is associated with confidence in successful delivery. Also pay particular attention to a rigorous start gate…” 

Prince2 is a generic gate process method, applicable to any type of project. There are other gate process methods which are specific to various industries and project types.

    ❑    One of the most developed stage gate methods is PetroGate, a method used in the oil and chemical industries. For example, a major chemicals company starts all major investment projects with up to four stages and gates. Gate four is the key decision point - at this gate, the investment budget is approved.

    ❑    In IT, various IT methods for solution development such the v-model have been translated into stage-gate project management methods. For example, the IT project teams in a major bank used a stage-and-gate method to boost the reliability of the handover to operations at the end of the project. The final gates checked that the right work had been done prior the hand over to the support teams and the project closedown.

    ❑    In New Product Development, many companies implement a funnel approach to product development using stages and gates. They generate hundred of ideas and start lots of projects. Weak ideas or unprofitable products  fail to get beyond gate 1 or gate 2. If a hundred projects are started, perhaps only 20 or 30 get into prototyping and development and under 10 get though the final gate which approves the product launch in the marketplace.

    ❑    In the construction industry, gated methods are used. As construction projects can be long, some industry methods can have many stages (ten or more). But if it’s a renovation project, there may be fewer stages, and if it’s a demolition project, there may be only one or two stages.
   
Be careful when you deploy gate-process methods. Avoid the traps
    •    Each project is unique, you should not  force all projects into a rigid structure. 80% of your projects may follow your standard method, but 20% of your projects should definitely not (but could still use a generic gate-process approach such as Prince2)
    •    Understand overlaps. Stages are sequential, but some teams need overlapping “phases”. (Prince2 explains how to handle this, although in the current 2009 version the vocabulary it uses is confusing)

So if you are a team manager looking to boost project management efficiency, check out gate-process methods. One good starting point is Prince2, because it is a general purpose gate-process method, which you can tailor to your company or industry needs.  Take a look … open the gate to more effective project management.

Avoid overload: manage your personal and project bandwidth

A trap is waiting for you in today’s busy world, where everyone is under pressure to get things done, lots of things. Do it all today! Get things done now!

The trap is multi-tasking. If you try to do too much at once, you lose focus and become less productive. It’s a trap at the personal level, and it’s a trap for project teams too.

To avoid the trap, you need to recognise your limits. A person has limited “band-width”.  And so does a team, a project or a company.

Multi-tasking sounds attractive. It’s a fashionable term borrowed from the world of computing. But if it’s great for computers, it’s a trap for humans when it overloads you. Overload destroys your focus and your productivity. If a task needs some prolonged concentration, some serious brain-work, then you need to reduce your multi-tasking.

It’s a trap that project managers can fall into. Some project managers abandon good practice and try to run their project using a to-do list. They are inviting overload and burn-out.

There are several easy and effective ways to avoid the trap.

1) At the personal level, and for small teams, Kanban approaches can work well. Kanban is a “lean” technique, where you have a backlog of work (your to-do list) but you limit the work in progress using a visual planner. For example, you may decide that only one task per person can be “in progress”. When the task is finished, start another. If you don’t finish it, put it back on the backlog list, then start another. (Read more about personal kanbans here)

2) At the project level, traditional methods like Prince2 use planning and delegation to maintain focus, while Agile methods use scope management.

    ❑    Prince2 uses planning to focus on your current work: Prince2 breaks the project into stages, and the project manager focuses on one stage at time. Prince2 has a simple and effective planning technique – with a clear and simple stage plan, you know what work needs to be done this week or this month. The plan replaces the to-do list and allows the project manager to focus on a limited number of current tasks.

    ❑    Prince2 uses delegation to sharpen your focus: Prince2 breaks the work into deliverables (or “products”) that are delegated to sub-teams. Each team has its own team manager, and the project manager doesn’t micro-manage the sub-teams. The delegation of work reduces the load on the Project Manager, who can focus on managing the project (rather than on doing the work).

    ❑    Agile approaches often focus on delivering just the right scope. Methods like ATERN (also known as AgilePM) use MuSCoW prioritisation as a way to avoid overload. Business needs are prioritised as “Must Have”, “Should Have”, “Could Have” or “Won’t Have”. If the project manager or the teams are overloaded, they concentrate on the “Must Have” needs. They know how to focus – they reduce their bandwidth, knowing that the “Should Have” and “Could Have” needs can wait.

3) Sometimes the problem is wider than the single project; it’s at the portfolio management level. Companies need to avoid overload, they too have limited bandwidth for change. MoP (Management of Portfolio) addresses this with portfolio prioritisation models, which can take into account both resource capacity (do we have enough people?) and resource capability (do we have the skills?)

So next time you need to handle pressure, don’t just build a to-do list. Don’t try to do everything at once - multi-tasking is a trap that can destroy your productivity.

That glitzy to-do list app on your smart-phone is tempting. It’s perhaps a good tool, but it shouldn’t be the only the only tool in your toolbox. Don’t run your life or your project using a to-do list, you will run into overload and stress. Widen your horizons; add some additional tools to your toolbox, either traditional tools like planning and delegation or innovative ones like Kanban and MoSCoW.

P3M3: behind the acronym is an important tool

Project Management is full of acronyms. PID, WBS, ROI… there are hundreds. Some of them help us, some of them confuse us.

P3M3 is a troublesome acronym that’s been around for a few years. Some people like it, some hate it, some don’t understand it. P3M3 is certainly not a good acronym, but don’t be put off. Take the time to understand it, and you will discover a useful tool-set that can help any organisation to measure its progress in Project Management and related areas.

Firstly, let’s decode the troublesome acronym. It’s a confusing acronym, because the acronym is not the sum of P3 + M3, as you might expect. No, P3M3 is the fusion of two other concepts, MM + P3M (but neither concept actually exists as a stand-alone acronym)

    1.    MM is about Maturity Models
    2.    P3M is  Project Management, Programme Management and Portfolio Management

So P3M3 is about measuring your team’s maturity to manage projects, programmes and portfolios. 

P3M3 comes from the UK, and belongs to same family as Prince2, MSP, MoP and P3O. If you are using one or more of these methods, then it will directly help your team to measure your progress; if you are not, then don’t worry, they are designed to be general purpose models, and you can still use these tools.

Let’s deal with the two parts separately

1) MM = Maturity models.

P3M3 is based on models, which help us to measure maturity. Each model tries to express one aspect of maturity. 

A maturity model attempts to measure your team’s maturity, on a scale from 1 to 5, based on defined best practice. It’s not just an arbitrary measurement, it’s a well designed model based on a set of criteria founded in proven best practice.

For example, P3M3 contains a maturity model for project management (called PjM3). This is based on a 360° set of measurements of project management maturity, using 7 dimensions such as financial management, risk management and resource management. This can be used by any team, whether it is using Prince2 or not. For the Prince2 community, there is dedicated model to measure the team’s ability to run better projects using Prince2. (This version is called P2MM).

2) P3M = the management of change initiatives (projects, programmes and portfolios)

P3 is a useful little acronym. It stands for Projects, Programmes and Portfolios. These are increasingly called “Change Initiatives”. They are three different ways of managing change.

Project Management has been around for years, and many organisations have reasonable maturity in project management. Programme Management is more recent, and Portfolio Management is the new arrival. All three are tools for change, to help the organisation to manage change efficiently and effectively.

So P3M is about management of change, and P3M3 is about measuring your organisation maturity to manage change.

Some organisations manage change well. They implement a strategy which changes the organisation. They innovate, adapt and survive. Their change management is effective.  When they invest in a project (or a programme or a portfolio), they can expect a good return on that investment.

So that is why P3M3 is so important. It measures your organisation’s ability to change. To innovate. To adapt. To survive.

Concretely, P3M3 drives improvement. It helps you to assess your maturity, objectively and with a structured 360° view. When you know your strengths and weaknesses, you can improve. If you know that, for example, your project financial management is fairly strong (say, level 3), but your project risk management is weak (level 1), you can launch some targeted improvements in risk management.

That’s a fast track to improvement. A fast track to better management of your projects, programmes and portfolios. Which means more efficient and more effective change management for your organisation.

That’s why P3M3 is so useful.