The Money Files

This month it’s all about celebrating project success here on ProjectManagement.com, and with that in mind I wanted to explore some ideas around what makes a project successful.

Malcolm Gladwell has been instrumental in shaping my thinking about this, and you can read more of how I got to know of his work and his thoughts on the paradox of successful cultures in this article.

Often times, we rely on the old adage: “Fast, good, cheap: pick any two.”

The assumption here is that if you don’t pick ‘cheap’ and you have plenty of money to invest in your project, then you’ll get a successful outcome. We also hear leaders talk of being able to throw money at a problem.

Don’t get me wrong. Having money to help resolve issues and to fight off potential problems is a huge benefit. Funding does make many issues seem less troublesome. When you can call in extra resources or buy more stock without worrying about it, that’s definitely a burden removed.

The thinking of Gladwell, author of Blink and Outliers, suggests that successful cultures aren’t the ones with the most money to throw at problems. Success doesn’t come from unlimited funding.

Borrow and Follow

Successful project cultures are those that rely on the ‘borrow and follow’ approach that Gladwell laid out at the PMI Global Congress North America in Dallas where I heard him speak.

Those project management cultures don’t innovate – at least, not extensively. They look at what is working and adapt processes to their own environment. They actively pay attention to lessons learned. They work hard to build organisational knowledge and avoid the mistakes of the past – following in the footsteps of those who have done good work.

In other words, don’t reinvent the wheel if you don’t have to. Let someone else do the heavy lifting. In project management this could look like:

• Using a standard, published, recognised body of knowledge instead of trying to write your own
• Using best practice processes, instead of trying to design your own
• Having a robust and followed lessons learned process so that continuous improvement becomes part of the fabric of the way things are done (whether that’s using Agile approaches or continuous review during a sequential-style deliver)
• Using existing published career paths and competency models for your project managers instead of trying to write your own
• Using existing, recognised training and credentials for your project managers and team members instead of trying to design in-house training schemes.

There’s no requirement for ‘success’ to start with a lot of hard work in setting up systems that already exist elsewhere. While you should always be mindful of taking intellectual property and reusing it as your own (ethics is always paramount), there are plenty of materials, processes, templates and more out there that mean you can create a successful project management culture with a smaller initial outlay.

The Negative Side of Funding

The other interesting idea that has come through Gladwell’s thinking is the concept of money constraining creativity.

In other words, the more money you have, the less creative your project environment is likely to be, and that can have implications for success – both on a project level and on a portfolio or PMO level.

You’ve probably seen this yourself in your workplace. When money isn’t an issue on a project (if you’ve been lucky enough to be in that kind of environment) then you’ll know that when you hit a problem, the first thing the team thinks about is how to buy their way out of it.

When I researched my first book, Project Management in the Real World, I included a case study of a build project where the team had to work creatively together to find ways to hit the project budget. The project was a success because the effort of having to think creatively around funding brought the team together. The closer working relationships they forged when together the various suppliers worked with the project’s objectives front of mind made it a better project for everyone.

Money Doesn’t Equal Success

I don’t doubt that money makes projects more likely to hit their objectives. The experience of working on a project with adequate funding is more pleasant than having to scrabble for resources, count every penny, and challenge every receipt. But it isn’t the only thing that makes a project successful.

Think about your projects and what success looks like for you. How much of it is determined by the funding available and how much by the talent of the team, the timescales or the commitment of leadership?

What do you think about this topic? I’d love to hear your thoughts so let me know in the comments below.

What’s the difference between a stakeholder and a supplier?

I was asked this question recently and I thought it was quite simple to answer. It turns out, as I started to formulate my response, that it is a lot harder to pin down than I anticipated.

Partly, I think, that’s due to the “flexible” nature of project management jargon. What’s a stakeholder for me might not be so defined by the methodology you use, or the common terminology used by your PMO.

I think the difference is easier to explain if we look at what each of them is. The comparisons, similarities and differences then become more transparent.

What is a Stakeholder?

For me, a stakeholder is anyone who has an interest in the project.

Primary stakeholders are those who do the process. They agree what will and won’t be in scope of the project. They know how much they are prepared to invest, both in terms of time and money. This group is going to shape the project and includes your project sponsor and the people who sit on your Project Board.

Secondary stakeholders have less of a vote in the way the project is run and the outputs it will achieve. They may shape and define the result, and you’ll listen to them as they are affected. The project might be quite challenging for them, and you’ll want to involve them, but they aren’t key decision makers. This group would come to meetings, maybe take part in a workstream and do smaller tasks.

Interested stakeholders are curious. They might feel like they want a say but they have no managerial interest in how the process is performed, they are not a supplier, and they are not involved in delivering the project or process. These are people you meet at the water cooler or coffee machine. They have a view, but you may or may not want to listen to it. It would depend on their level of influence over the opinion of people you do rate on the project.

Stakeholders can be internal or external. Internal suppliers work within your organiation, so your peers, managers, colleagues. They are people on the payroll of your business.

External stakeholders are the opposite: they are people outside your organisation, and that includes suppliers.

What is a Supplier?

When most people think of suppliers we think of organisations from whom we buy goods and services for our project. This would include:

Hiring equipment e.g. cement mixers, venue hire, kit of a any kind

Providing a service e.g. contract developers, subject matter experts brought into the project for a particular purpose such as specialist lawyers, trainers. Contract staff members joining the project team would fall into this category, even if they were on staff for the duration of the project and work as if they are a member of the in-house team.

Providing goods e.g. vendors from whom we purchase equipment or products for the project like computer chips, raw materials, steel etc.

These organisations or individuals are normally external. You can’t source the goods or services in-house so you go externally to procure them.

The other thing they have in common is that we typically pay for them.

However, suppliers could be internal, if your internal labour market is set up that way. IT, for example, could be a supplier of development resource to your Sales project, and they could charge you for the time and effort of the team involved. In this respect they would be a supplier and would act like one. You’d probably have a formal statement of work, estimates drawn up and so on.

I’ve only worked in one organisation like this but it is perhaps more common than you think, especially in the biggest organisations and the public sector. Personally I’m not convinced of the value of this kind of internal economy, but I mention it because there might be times where a supplier (in terms of your project) is actually someone who sits down the corridor from you and works for the same entity.

Managing Suppliers as Stakeholders

I think we can conclude that suppliers are a subset of your stakeholder group. They should be managed and engaged as any other stakeholder group. That means including them in your stakeholder analysis.

It’s important when working with people who are strategically important to the success of your product e.g. package software provider, to think about their involvement in the project and to do what you can to set them up for success. In other words, you could involve them in project communications. They might need slightly different versions of your communications because you might not be able to share company confidential information with them, but broadly you should treat them as per your stakeholder analysis suggests.

To conclude, suppliers have a distinct role to play but they appear in my stakeholder management plan. I would put suppliers as a sub-group of my stakeholders. I would classify them as external primary stakeholders. In other words, they have a core role to play and are influential in both shaping and delivering the project, but they aren’t employees.

How would you state the difference between a supplier and a stakeholder? Perhaps you can do it in fewer words than me! Let me know in the comments section below.

In this video I share a few quick tips for preparing for a project audit. It shouldn't be a scary event and yet some project managers still feel daunted by the process. I get it - it's time consuming and it does feel like you are in the spotlight for a while. But the outcome is worth it, as long as the process is robust.

Mohamed got in touch via the Project Management Café Facebook group, and asked an interesting question:

What is the difference between the below 2 jobs:
-Technical Project Manager.
-Technical Service Delivery Manager.

Great question, and I’m sure many people starting out in IT wonder the same, especially in environments where the Tech PM is paired with a business project manager or change manager, or working with a programme manager. In that kind of environment, the distinction of who is running the project can be a bit blurry to the uninitiated.

Technical Project Manager and Technical Service Delivery Manager (or simply ‘Service Delivery Manager’) are two very separate and distinct roles in an IT function.

What the Tech PM Does

A technical PM works on delivering change. They lead a project, and in this case it would be an IT project, or the IT workstream of a larger project that involves other business teams. In some structures, other business teams might work under the IT project manager, if the PMO and project management expertise sits in the IT function and other business areas don’t have their own project delivery capability. The exact set up is going to differ between companies and organisations depending on the skills and hierarchy of the business but whatever the set up, one thing is clear: the tech PM does work that delivers projects.

They implement new processes or services, or deliver products and facilities. Their work centers on changing the environment.

What the Service Delivery Manager Does

A Service Delivery Manager works on achieving a successful status quo. They are focused on the running the business. They might be responsible for a particular service line and making sure that runs effectively. Or they might face off to a business area and support them, so they are focused on ensuring those teams have the infrastructure and tech set up required for them to do their day jobs.

The role of the Service Delivery Manager can encompass anything required to keep the lights on for the IT services they support. This includes managing changes to operational services through a Change Advisory Board, taking on board customer feedback, managing service outages, liaising with suppliers and being responsible for maintenance contracts.

There are processes to follow to ensure that there are no service interruptions, or if there are, these are dealt with effectively to keep the business running.

Bimodal IT

I don’t really like the phrase ‘bimodal IT’ (was it Gartner that coined that?). In project management we’ve had this distinction forever: it’s the same as the difference between projects and business as usual.

• Some people change the business (these are the project managers, our Tech PM).
• Some people run the business (these are the operational teams, and in this case, our Service Delivery Manager).

However, if you want to use the jargon, bimodal IT describes these two states of being: maintaining the status quo and at the same time changing it. And this is where the overlap between the two roles comes in.

Project Handover

The roles overlap because project managers deliver into live service. We want our products to be used, and they need to be incorporated into the live operational service for the organisation.

To take an example: say you launch a new web service for customers, so that they can pay for your services online. The project goes well and you launch the service. The new web pages are up and running. You then move on to a different project.

If you did a good handover, the operational team will know how to process orders that come from the website pages. They will know how to support and maintain the web pages and they’ll have an idea of what acceptable service looks like.

The Service Delivery Manager will be involved in this too because they will be responsible for the IT elements of the website. For example, the handover would ensure they are equipped to:

• Manage upgrades to the content management service
• Patch the web servers appropriately
• Ensure anti-virus is up to date
• Deal with calls from employees who are trying to access the data captured on the website or other queries
• Be able to reset passwords for the admins

And so on.

The Service Delivery Manager needs to be ready to catch the ball when the project team throw it over.

Handover is Too Late

Having said that, waiting until project closure to start working together is too late. If the Service Delivery Manager hears that there is a project that touches his or her area, they should investigate. The project manager should involve them as early as possible.

Why? Because they know so much about the area they support, their products and services. They can be crucial in creating a product that is actually supportable. You wouldn’t want, for example, a web microsite to be created on a different content management system to the main website, as that would mean two lots of content management systems to support, two lots of admin and password resets to handle, and so on.

I actually know a company who did this. Perhaps there was a reason for it at the time – I never found out, and it always struck me as odd that they’d created extra work for the operational teams through not involving them early enough in the design process.

To summarise, then:

The project manager moves on. The Service Delivery Manager is a long term operational job, stuck with managing and maintaining whatever the project manager hands over.

Make sure you are handing over something supportable and decent, by involving the right people early enough.

Here’s a short video sharing three ways to keep your project on budget, but be warned, these are suggestions for project managers willing to take the difficult decisions and have hard conversations!

You can see more tips on how to keep your project on budget in this article.