The sun will shine on you again, be ready

Being ready to go on the B of Bang

I've had a few obvious quips when talking about protecting assets with PPM. It is not about having a mechanism to hide behind, it is all about giving your team the chance to be successful in an open and transparent manner. IT Teams and Budgets are always under strain with too much being wanted from too little. PPM is the framework that amongst many things aligns projects to resource and budget capability.

If I deliberately over simplify, IT can be split into Run and Change (sorry to my DevOps evangelist friends, just go with it for now). Run is the team and budget required to keep existing services and systems running. Change is the budget and capacity for projects to change or add new business capabilities. I could go into pages and pages of theory about who owns the change budget, but for simplicity in this instance it is within IT. In this scenario, if the Change side of the budget takes on too much work, it will either fail or lean too heavily upon the Run teams/budgets which in turn will lead to quality issues with existing services. Does this sound familiar?

With PPM, IT steps into the role of facilitator and provider of factual information for our business colleagues to use. What IT has is a capability and a budget (capacity) that it can use on behalf of the business. IT should never put itself in the position of choosing what that Change capacity should be used for, why would you ever put yourself in the "well we didn't want that anyway" interrogation spotlight? Instead, IT should be working in partnership to facilitate the construction of Business Cases that can compare "apples with apples" when being ranked for impact.

In PPM, IT can become the guardian of business case construction, helping ensure that tangible, intangible and dis-benefits are all quantified in an even handed way. Unless it is a specific IT Project, the IT Director is not responsible for delivery of the benefits identified within a business case, however they have input to them and IT will be responsible for the determination of cost to deliver. It is therefore in IT's interest to ensure that all benefit and delivery cost estimation are realistic and grounded.

With grounded and levelled business cases being used to sell the case for each project on its own merits, IT's capacity to deliver can be protected. The business cases are capacity matched to the available forecast capacity with on-going programmes and projects being taken into account. If requested Change is going to breach capacity it is then a question of how best to bridge that gap rather than closing your eyes and taking on more than you can deliver. That IS a conversation you want to have with the business.

When is a Project not a Project

This all sounds too simple, Run v Change, very clean and clinical. Well yes it is a nice panacea, however there are Change initiatives that we should consider and to make sure they don't confuse issues we should ensure we don't refer to them as projects;

• IT Maintenance - if IT were to include all the maintenance/upgrades it requires to remain safe in PPM then they would get voted down every time. To ensure that IT has the capacity to remain current and safe, the IT budget should include its own Maintenance line. This is resourced outside of the PPM governance.
• Rolling Programmes - items such as CRM or ERP may need a specific ring-fenced resource. They are budgeted as a "commitment" in those areas from the business. They will be run as their own PPM in miniature, i.e. selecting the highest value backlog items. It is similar to PPM as it is all about choosing the highest value items that can be delivered by your capacity.
• Small Change - PPM is not a quick rapid-fire process. It takes a lot of information-gathering and presentation as well as getting senior executives around a table. It can only happen as frequently as is required for the company in question. Not all Changes can wait for the PPM cycle to complete, it may be detrimental to do so. To cover these what I call "Small Changes" IT must leave itself a budget and resource line for doing rapid-fire changes. It does need to guard against cunning stake-holders trying to break projects down into small changes to circumvent PPM, that will unfortunately always happen.

TCO and The Cost of Not Doing Something

PPM is all about the Business Case and graphically illustrating where the value lies so that joined up decisions can be made. Like all methodologies it can be lightweight or in-depth depending usually on the size and agility of your business. In both the lightweight and in-depth versions there are certain things that must be taken into account. The two things I see left out the most often when defining a framework are Total Cost of Ownership (TCO) and the Cost of Not Doing Something. These two are very closely linked, many times the Cost of Not Doing Something has a direct impact on TCO. This is why they should always be considered as if the TCO goes up, then Run budgets need to be considered. It is important in enabling the continuation of the Run side of IT.

Boulders, Pebbles and Sand

Planning project capacity is never an easy challenge, some people (including an IT Director I have worked for) say that you shouldn't bother as the time required to get it accurate means that by the time you have worked it out it will have changed anyway. I have to say there is some credence in that thinking, but it would take a brave Portfolio Manager to not understand the capacity they have across certain skill-sets. For me it is about getting the right granularity. Consideration has also got to be given to many factors such as Change Management, Training Capacity, Seasonality and Release Schedules. In considering these factors an approach known as "Boulders, Pebbles, Sand" should be used. There is a very common visual that goes with it, it shows how you can maximise the space taken up in a container if you pack it with a mixture of Boulders, Pebbles and Sand. These represent the magnitude of your projects; don't just focus on cramming in the big hitters, it won't maximise the return on your efforts.

Agility but not necessarily Agile

It is not possible to convey everything about PPM in one relatively short article and I would be daft to think I could, so the last thing I'd like to mention is the A word. PPM does not dictate or influence project methods; that should be dealt with in the Project Delivery Framework. As much as I'd love to delve deep into when to use Waterfall and when to use an Agile method, this article is not the place for it. What I do want to say about the A word however is that Agility is a key principle within PPM. Because of the relatively long cycle time of PPM it is essential that changes to projects or benefits can be considered as an exception to the straight-line PPM process. This ensures that the PPM process does not become an inhibitor to decisions being made in line with rapidly changing circumstances. This exception process needs to be clearly communicated to and understood by all stake-holders.

PPM is a relatively simple process however it does have disciplines and complexities that need to be considered. One of its biggest challenge is keeping the momentum and interest. That is all about stake-holder management, maybe another topic for a lock-down driven article?

So, in summary, whilst you have time to plan and most of us unfortunately have that right now, why not put extra focus on your PPM process. If you don't have a PPM framework/process, then why not dig a little deeper and look at how it could benefit how your company maximises your IT spend/capacity?

• Let the business own the "what we need" decisions
• Share the understanding of cost to deliver with Project Sponsors
• Make Run and Change budget impacts transparent
• Be the facilitator not the decision maker

About the author - Des Scanlan is an independent IT Professional available for short-term consultancy/contract work. He is also the principle of Des Scanlan IT Recruitment which only supplies candidates who can do the job well - knowing what good looks like.