What makes a project manager successful? It’s no secret that it’s hundreds of small decisions and behavioural traits. I’ve been thinking recently, as I’m writing a new book, about the things I believe make the biggest difference.
The infographic below isn’t based on scientific research, but on my experience working with project managers and leading teams. What do you think makes the biggest difference in whether a project manager is successful at work or not? Let me know in the comments, I’d love to hear!
What a great question: is it worth moving clients to a retainer model for project services? A got in touch to ask me, and I thought it was probably a question worth sharing with everyone here.
This is what she said:
“We're a small graphic design studio with 3 employees. My boss wants to convince some of our clients to move to a retainer model. The thing is, most of our projects are on an ad hoc basis, without much consistency from month to month. My feeling is a retainer is not ideal in such a situation, but my boss likes the appeal of it... Money in the bank every month, how wouldn't you?! So my question is: when would you recommend a retainer, and when would you advise against it?”
What is a Retainer?
A retainer is a fixed fee that the customer pays you every month to secure a certain amount of work done. The work could be anything, as long as it’s covered by the scope of your agreement.
Sometimes hours not used are carried forward (often by a limited amount e.g. use within three months or forfeit the hours). Sometimes they are written off if the client doesn’t use them (which is the arrangement I have with a supplier at the moment).
Let’s look at the pros and cons of this payment model.
Advantages of Working on a Retainer
First, the most obvious advantage: it’s money in the bank every month! Whether you do the work or not! What manager wouldn’t want that? I totally get it.
This model works well for projects where there is an element of continuity. I know project have a start, a middle and an end, but if you have projects where there are incremental improvements planned over a year or so, you can see that having the commitment to move forward works well. Think design clients, web projects, app development, that kind of thing, although I’m sure there are other industries where this would also work.
It can improve the flow of work from the client. When they know they have committed to pay a certain amount for work done each month, you might find the work planning is easier. They should be letting you know what they need you for in advance of the next month. This can improve the consistency both of the incoming work (better for you) and the communication (better for both of you).
You should get to know them better and what they want, and that might help you advise them on how to use the retained hours each month. You are also more likely to prioritise their work above incoming fixed-fee or ad hoc projects, just because you have a relationship with them that’s different. That could be a selling point for clients.
Easier admin: both for you and the client. It’s one invoice, it’s a fixed fee, it can be largely automated as a recurring payment. It should be easier for you to maintain the relationship and manage the payment cycles (although for your own benefit and for “proof” you’ll still have to do timesheets). Fixed costs for the client could be a real plus point.
Disadvantages of Working on a Retainer
There are some disadvantages of course, for you and the client. First, you never know how much work the client might want you to do – if it’s a slow month you might be able to squeeze in extra ad hoc work from other people. It’s better to plan for all your hours to be used up so that you can definitely resource their work, but if they don’t send work your way you might have project staff waiting around.
Normally you’d charge your client less per hour on a retainer than you would for a project-driven rate – that’s the advantage to them of having a retainer.
The client might decide that if the work genuinely is ad hoc, that they don’t want this model and you’ll end up either going back to the way you worked before or potentially losing the client if you no longer offer that as an option.
Transparency becomes more of an issue. If the client doesn’t believe they are getting value for money they will vote with their feet and take their projects elsewhere. Think carefully about how you are going to do demonstrate what you have done and what value they have got from their investment each month.
So: When Does a Retainer Work Best?
I think the retainer model works well when the scope of the work is broad, ongoing or likely to evolve. In other words, where the requirement for a long term relationship seems apparent from the start. This might be through lots of micro projects such as graphic design projects, or through one larger piece of ongoing work.
It’s also an effective way of working where the breadth of the work required stretches over several teams or the capability of a whole agency/supplier. You aren’t costing hours per different type of specialist resource within your team, you’re quoting for work done on a flatter cost structure so it removes admin.
I have paid retainers before (and still do) but I am interested in hearing your thoughts on how this works in your business. Let us all know in the comments below, and thanks, A, for the thought provoking question!
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:
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.
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:
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.
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.
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.
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:
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.
When you’re putting together a new project proposal, there are a number of things to consider. Edoardo Binda Zane has a whole book about proposal writing: Writing Proposals: A Handbook of What Makes Your Project Right for Funding. He says that there are three main elements:
Project proposals of this kind are quite different from in-company project business cases. These relate to projects where you are basically pitching another organisation to give you funding for your project. This happens in research, academia and sometimes other areas like business incubators for start ups.
Let’s say you want to put a funding proposal together for a business incubator. You know you are eligible and you’re gathering the paperwork to prove it. You can put your budget together in the format they want. But the technical proposal…. It’s hard to know exactly what goes in that, even if you know your own solution perfectly and have already costed it. This is about communicating the value and approach of your project so it gets chosen over someone else’s.
It helps if the funding-granting body has given you a template to complete. That certainly takes the guesswork out of it. If that doesn’t happen, you’ll be reliant on your own internal templates and they might not be geared up for this kind of application.
Binda Zane has some pointers for what to include. The headings below are what he suggests goes into your technical proposal along with an explanation of how I would interpret those if it was my project.
Pop something in here to set the scene. Personally I would write the introduction last so I could make it contextually relevant to the rest of the document. If you don’t normally leave it to the end to write the intro, try it next time – it’s so much easier!
Current context and proposal structure
This should cover the context of the project and any background information that’s useful for the decision makers to have. It could also describe the research you’ve done (not in detail) or other sources from which you’ve drawn information to prepare this proposal.
It’s also a kind of executive summary that outlines what they can expect to read in the proposal and gives them the headlines in an easy to digest format.
You’d cover off the project goals and objectives. This would be just like a standard business case.
Binda Zane suggests that you talk about the tools and techniques to be used. This can give the decision makers confidence that you do have some clue about how to manage a project. If you can say that you’re using industry standard best practices and following guidance from PMI (or whatever methodology/standard/processes are applicable to your business) then do.
I’d make sure that governance gets a significant mention here. If you were asking for my money I’d want to know that you had controls in place to spend it sensibly.
Of course, you shouldn’t say that you can follow standards if you actually can’t. That would be a breach of the PMI Code of Ethics and Professional Conduct. Other professional bodies have similar ethics standards.
You’d also want to include a section that outlines your detailed approach, the work packages and the descriptions of each task, at least to a sensible level that tells them what you are all about. If you think this section might go on a bit, move some of the task descriptions or detail to the end and put it in an appendix.
Organisation and Staffing
This section covers what they need to know about the people who will be involved with the project and how the work would be organised.
Binda Zane suggests management of quality control is covered in this section but I think there’s some flexibility to move it elsewhere if that makes better sense to you. I think I’d include this in my methodology section but there could be good reason for keeping it here.
Up until now you’ve only talked about what you will do, and how you will do it, but there hasn’t been any talk of how long that will take. Mention the timescales, major phasing and anything else relevant: key milestones, reporting dates and so on.
You also want to talk about the project team in this section. Describe the make up of the team, the organisation structure for the project and the roles and responsibilities of the key players.
Binda Zane recommends two appendices. You can dump information in here that would take up too much space in the main proposal but is still useful for the audience to have. His suggestion is that you include the CVs/resumés of the project team and also a selection of project references. By that I would surmise that you could include references from past clients about similar projects, awards your team has won for their project work and anything else that makes you look like a solid and stable organisation.
That should give you a solid project proposal – for the technical element, at least. What else would you include in a technical proposal? I’m interested to hear your thoughts about what might be missed out of the list here!