There are loads of different ways of categorising projects, but I came across a way that was new to me recently. There are 6 categories of project outlined at high level in a UK government publication about creating a project business case.

I’ve summarised them briefly below.

1. Standard building projects

Let’s start with the building projects. A ‘standard’ building project is one that pretty much uses a building blueprint that’s already available. There are no special design considerations, no fancy extras or design features to incorporate.

Examples:

• Office buildings
• Residential buildings (not self-build or fancy architect-led projects)
• Airport terminals
• Hospitals
• Schools

2. Non-standard building projects

Anything that is not a standard building construction project is a non-standard project. These are constructions that have special requirements or must meet certain conditions, perhaps dictated by use or space or the requirement to incorporate some high-tech feature.

The environment around the construction might also make the project non-standard. For example, if the site has some special archelogical, scientific or envrionmental significance. Or it could be that the building is going on the side of a mountain or in a cave, or something like that.

Examples:

• High-tech facilities such as labs or research facilities (think: a polar exploration hub)
• ‘Destination’ buildings: when we visited the Arctic Circle, we stayed in a hotel that had rooms with huge windows in the ceiling for watching the Northern Lights.

While I was in a previous role, the company acquired an old building and changed its use, but had to keep the existing façade. I’d put that project in this category as the complications around what we could and couldn’t do within the footprint of the building made everything quite a challenge.

3. Standard civil engineering projects

Straightforward civil works would use tried-and-tested techniques. There’s not much else to say about these.

Examples:

• Roads
• Utilities like electricity plants or water treatment facilities.
• Railways.

4. Non-standard civil engineering projects

Do you see the pattern? Unsurprisingly, non-standard public sector and civil works include things that don’t fit the mould of the standard work. They are non-routine constructions.

Examples:

• Upgrades and extensions like the Jubilee line extension on London’s underground system
• Utility projects where the environment is non-standard or constrained in some way
• Build projects like railways that require additional features or technology.

5. Development and equipment projects

If you’re not building something physical, you might be building software or doing some other kind of development. These projects move an organisation forward and help get things done. They are often the work that underpins strategy delivery and can be big or small.

All the projects I’ve ever worked on fall into this category, as I don’t work in construction or outsourcing (which we’re coming to).

Examples:

• Software development
• Process change
• Provision and installation of equipment into facilities.

These could be cutting-edge tech deliveries or simply upgrading your old phone system or something equally routine.

6. Outsourcing projects

Finally, projects that have the end result that something is outsourced. That could be providing a client with cloud computing solutions or running a building for them, and typically it’s all about ‘something as-a-service’.

Examples:

• Equipment maintenance
• Setting up a new helpdesk for IT queries
• Providing whatever it is you provide as a package to the client where they have outsourced provision of that service or product to you.

Do you think this is a good way to split up projects? I’m not sure that I do – there isn’t enough granularity of the ‘development’ projects for me. Maybe they are all unique and we don’t need to split them between standard and non-standard. Most of the things I’ve worked on have felt non-standard at the time.

What category of project do you work on? Let us know in the comments below!

Let’s talk about commercial viability for your projects.

Commercial viability is something that is considered at pre-project stage. It’s all about proving that it is worth going ahead with the work because the figures make sense. It’s typically related to working with suppliers: your analysis establishes that the relationship is commercially viable, which means you’ll both get something out of it and it is worth the time and effort involved.

A commercially viable deal will be one where the procurement decisions and contract offer the best value to the organisations involved over a time period that makes sense for the deal.

One of the challenges is that what sounds commercially viable today might not be tomorrow, if the market changes, or a supplier goes bust, so it’s important to take a proactive approach and be as risk-aware as possible.

We’re now in the realms that – in my view – stretch outside of a project manager’s remit. As the project manager, it’s unlikely that you’ll be signing the deals or commenting on the financial viability of the partners you are about to start working with. But you can make sure that the right people are involved on both sites.

Here are some things to consider.

What procurement options are available, and have they all been considered? What are the contract terms and is there a break clause? How long are you locked in for and is that acceptable?

What do both sides need out of the deal and what are the requirements?

Where does the risk sit, and if it is with your organisation, is that acceptable? What does the risk profile look like when aggregated across the programme? Do you feel that the supplier is taking too much risk to the point that it might jeopardise their ability to remain commercially competitive?

How and when will payments be made? That can affect the commercial viability of a project because it impacts cash flow. Large payments need to be pre-organised in my experience, so they can made in a timely fashion. What are the payment terms – you might be surprised at how often payment terms are a sticking point for negotiations! We all want the money in our bank for as long as possible…

How will the money spent or earned show up on the books? The accountancy treatment is something that the Finance team will agree. For example, exceptional spend might appear below the bottom line. Some items might be capitalised; others will not. This is out of your control as a project manager, but it gives you confidence to know that someone has considered it and made a definitive choice as to how these things are going to be handled.

Finally, are there any staffing requirements that affect the business case, or the chances of the deal being commercially viable longer term? For example, with the supplier provide staffing, and then when those individuals leave, you have to pick up the resource requirements internally? Build in any costs of handovers, transition planning, a drop in efficiency while new members of the team get up to speed and so on.

All of these discussions take place at various levels, and the summary ends up in the business case before a project is approved. It’s just worth having them on your radar so you can prompt the right people at the right time and get the best possible start for your project.

Do you have a formal Change Control Board (CCB)? If not, this is the perfect time of year to be thinking about levelling up your processes and putting new ways of working in place to formalise the way change management is done across projects, programmes and the portfolio.

A Change Control Board is simply a group of experts that represent different organisational departments and who oversee both the process of change management and the different changes being put forward.

At a project level, your CCB is a group of people who know the project well and who can assess project-related changes, but at some point if your project is making changes to the live environment, like most IT and business change projects do, the change will need to be submitted to the wider, department or organisational CCB.

The role of the CCB is to:

• Assess the change
• Approve the change – in my experience, if the project team and project sponsor has already approved the change, there are few reasons why the CCB would then block a change
• Schedule the change
• Keep records about changes.

How it works

In our CCB, the functional lead or the project manager had to present the change. We had to talk about what it was, why it was useful and what it solved, and then make the case for whether it was a priority fix or not. If the change was considered a priority, it could go in the same day (mostly). If it wasn’t, it could be packaged up with a bunch of other small changes and go in the next release.

That made it easier to communicate changes to the end users.

Discussing the change

First, the change should be analyzed and discussed to see whether it has impacts beyond what the project team can comment on. The Change Control Board is convened to do that. I think the CCB is a really useful group and we relied on it in my last job. Our CCB looked at operational and project changes so the team could see the impact of ‘normal’ changes as well as the project-related ones.

I think it’s important that the CCB is made up of a cross-organisation group. It’s too common for changes (especially IT changes) to go in and for there not be a full understanding of the business impact somewhere else down the line. Complex ERP systems like SAP make that more likely, so a group of functional consultants getting together to discuss changes before they happen is a good thing.

I’ve had some changes rejected by the CCB because they didn’t have enough information to make an informed decision, or because something else was going on and they needed to wait on that, or because there was a change freeze. There might be many reasons why your change doesn’t go through.

Scheduling changes

The CCB can also schedule changes. There are normally scheduled windows to put changes in, especially in the live IT environment. That helps the support teams and the users know what is going to be different and what to look out for when they next log in.

Scheduling as a team also ensures that conflicting changes don’t get put in on top of each other. For example, if my project is updating the list of available categories in one part of the system, and another team is also updating that part of the system but taking away the category feature (that’s a bit extreme, but you see what I mean) then those conflicting changes can be discussed and overseen in an appropriate way.

It might involve putting them live in a particular order, or prioritising the changes so that one piece goes in this time and the additional change is put in next time.

I remember being told a story of a change in a data centre where engineers were working on cabling and flooring on both sides of a server stack. Without the support of flooring on both sides, the server stack toppled over! That’s the importance of making sure that changes are managed in a scheduled and sensible way.

We also had an emergency change procedure for anything that could not wait until the next release. On the SAP projects, for example, mostly things could be scheduled in a batch and changes pushed through on a fortnightly basis. But sometimes it was important to fix an issue straightaway without waiting until the next release. For example:

• Bug fixes
• Issues that affected customers
• Changes that went in and then didn’t work as expected.

All of these are emergency fixes to live systems that wouldn’t be appropriate to delay, and they are all issue-related, not nice-to-have features.

How does your CCB work?

I had a question recently which was: Where do project requirements come from?

In this quick video I try to answer that question! The TL;DR (or should that be DW?) is that you have to spend the time to talk to the whole stakeholder community to find out what requirements they have and what they are expecting. Only then can you start to prioritise and plan what’s actually going to be in the scope of the project.

How do you elicit requirements? Let us know in the comments section!

I think it’s important to understand project requirements.

I get that people want to be flexible and work things out as they go. But if you don’t know where you are going, how do you know if you’re on the right track?

It doesn’t matter to me how those requirements are documented. You can write user stories, or put together a waterfall-inspired requirements traceability matrix.

The important thing is that they are documented. The journey you’re on needs a destination.

Of course that destination might change. That’s what change control is for, or backlog grooming. You pick and choose as you go, being flexible and making alterations that mean you constantly add value. But at least there is some goal.

I’m thinking particularly of a project team that thankfully I wasn’t part of, but I know it was very frustrating for the project manager. Their role changed from being a ‘proper’ project manager to being someone who oversaw a team doing lots of small ad hoc developments and changes that felt very much like BAU enhancements, with no end in sight.

He needed to get out of that project, because effectively what had happened was he’d morphed into the role of product owner and the project had drifted into being a live service, without a formal close down and handover.

And I’ve been on projects where there hasn’t been anyone to handover to, so I’ve had to keep the support elements until someone could be made available. That is not fun.

 So if your project stakeholders are more inclined towards drifting to the finish line than working out the map to deliver their vision, then here are 3 benefits of documenting requirements to share with them.

1. A winding journey is a slow one

Do they want to get to the destination quickly or not? Perhaps slow is the correct approach. But in my experience businesses want fast results, with the least amount of money and resource time spent on getting there.

You can’t do that if you are constantly fire-fighting, dealing with changes, doing rework and coping with the misunderstandings and lack of clarity that come from not knowing what you are doing.

2. Better requirements = Better cost management

The same people who are reluctant to help you prioritise what should really be in scope could easily be the same people telling you to do the project cheaply and to keep an eye on cost.

If you know what’s in scope, you can budget better. The more stable your requirements – or at least the end goal – the easier it is to work out what it’s going to cost to get there, and how much you are prepared for that figure to be.

3. Documentation helps formalise the project

Is it really a project, or is it a piece of BAU continuous improvement?

If it’s truly a project, you should know it has a start, a middle and an end. You might not know exactly how you are going to get there. You might manage the work in different ways, with different methodologies or approaches. But ultimately, you know it’s going to finish.

Without documentation, it’s not clear to me whether it’s a real project. If you can’t articulate what you are doing, and your sponsor isn’t prepared to put it in writing, then that’s a red flag for me.

You can still put things in writing, however informally, and caveat them with saying things might all look different once the work starts or whatever. But having documentation increases engagement and makes the project work more formal. Which in turn makes it easier to get resources to commit to doing tasks.