The Money Files

A recent survey by GetApp, an online research company, sheds a bit of light on what’s really going on with project management software tools – which regular readers will know is a topic close to my heart.

I found the results interesting and here I’ve picked out a few to comment on. Starting with…

More than half of respondents (57 percent) work at organisations with annual budgets of $2k or more for project management software.

12 percent of respondents said their company had $25k or more to spend on software annually. My thoughts here are that the survey doesn’t correlate this to company size. You’d imagine that the cost of cloud software goes up with the number of users, so knowing the budget without knowing what they get for it in terms of project management population signed up isn’t very helpful.

However, this next point is interesting…

91 percent of project managers are willing to spend more for project management software that includes the missing features they need.

I’ve looked at a lot of tools and I have to say that there are similarities between what project management software does. After all, there are only so many ways to record tasks and mark them as complete. What extra bells and whistles you get for dashboards, resource management and so on are all good, but a Gantt chart is a Gantt chart at the end of the day.

So paying more for software that differentiates itself by having something “extra” – well, for many companies I think that is a hard sell.

However, this survey looks like customers will pay for what’s missing. The things they report as missing from the products they are using currently are:

• Task management
• Collaboration
• Budget management
• Integrations
• Idea management
• Chat tool
• And some others

No individual feature was reported missing by more than 12 percent of people, so there wasn’t a clear winner – if that’s the right term – for what is lacking in PM software. Rather, it’s a broad range of features that might not be in the tool you happen to be using.

The researchers draw an interesting conclusion from this, and I tend to agree: software hasn’t caught up with what project managers are actually expected to do these days.

It has been a while since the formal project manager was handed a fully-specified requirements document, and spent their days doing project scheduling, monitoring and control. Today we’re expected to handle a wide range of tasks from budgets to change management and everything in between.

And we need the tools that can deliver.

The amount people are prepared to spend on getting the features that matter to them is set out in the chart below. Most people don’t want to go more than 15 percent more and nearly 10 percent wouldn’t pay any more even if they got the extra features.

The challenge for software vendors is that every PM seems to have a slightly different set of requirements for what they need, at least in my experience. Even within my own business we use multiple tools because it’s easier and there isn’t one integrated product that does everything.

I’m used to it now, so I don’t see it as a problem. In itself that’s a problem! You can’t improve or look for efficiencies if you aren’t open to the idea that there might be some somewhere.

I’m not alone in using more than one tool, as the next survey result shows.

Almost three quarters (74 percent) of project managers surveyed use between two and five total tools for project management.

5 percent of survey respondents say they use over 10! I can’t imagine what they would be unless they have included software like Microsoft Word and email in their list. Perhaps they work with clients who use different products and as freelancers or contractors have to use multiple tools by default as every client has their own in-house specification.

Conclusions

This study seems to show that the situation for project managers today is that they don’t seem to be happy with the tools that are out there. With over 90 percent saying they’d pay for missing features and struggling along using multiple tools there sounds like plenty of demand for project management software vendors to step up.

However, I think that’s a sweeping conclusion to come to from this set of data points. I agree with the researchers that unless project managers have the right tools that help them do the job they are paid to do, we risk project failure (or at least not 100 percent success). But in my experience people are happy to talk about the things that aren’t going so great – and without access to the questions it’s hard to see if they were asked if there was nothing they felt was missing.

I’m naturally sceptical about surveys and I do think the data here is interesting. What do you think?

***

The survey was conducted with around 200 project managers in the US who use project management software for their day jobs. They came from a wide spread of industries but with a focus on IT and 49 percent of them had the job title Project Manager, with the others being slightly more junior or senior but still in PM-related roles. You can read the whole survey and see all the results here.

You’ve taken over a new project and you’re reviewing the business case. Or perhaps your sponsor has asked you to pick up a new project and you’re looking over the business case to see what you need to get started with.

In his book, Business Leadership for IT Projects, Gary Lloyd talks about the business case as a management tool. The book is of more value than just for IT projects, and I particularly like the ideas that the author provides when it comes to checking the validity and robustness of your project business case

Here are 16 red flags to look for in a business case. This is Gary’s bullet point list augmented by my take on what they mean for project managers.

1. Is the vision clear?

The vision is what people follow. If you aren’t clear about what the project is about in the business case, the people reading it won’t have a chance. It should be specific about the problem and what desirable end state is the result.

2. Is the scope unambiguous?

There’s always ambiguity at the start of a project, there has to be because you don’t yet know exactly how things are going to pan out.

However, points of ambiguity in a business case should be clearly pointed out, with risk budgets attached and plans about how clarity is going to be reached.

3. Have the key stakeholders been identified and engaged?

You might not want to do too much engagement prior to the business case being approved, but you definitely need people to know what is coming. If you are expecting them to work on the project in some way, they need to know that it is a possibility.

The red flag is when the stakeholder section in the business case looks skimpy. It should hold up to questioning: how much do these people know?

4. How was the cost saving or increased revenue calculated and tested?

The maths should be clear. A number alone isn’t going to give anyone confidence that all the variables have been taken into account. And if you can prove the numbers somehow because of desk-based research or a pilot or something else, then that should definitely be shown.

5. Is the worst case scenario really the worst case?

Is there a worst worse case? This is a good question to challenge a business case of a project that is mandatory or regulatory. Often those projects are started on the premise that ‘worst case’ is not being able to trade again, but that might not really be the situation.

You’ll also want to check what the worst case scenario is based on: if it isn’t to do with stopping trading if the project doesn’t happen, is the worst case to do with project costs, operating costs, missing out on cost savings, revenue or something else?

Dig into the facts and make sure your business case makes this really clear.

6. Does the project cost include contingency?

A no-brainer. If it isn’t there, ask where it is and be prepared to frown if the response is that the business case owner has padded all the estimates.

Contingency should be called out specifically for change budgets and risk budgets.

7. What is the change budget?

On the subject of change budgets, there is one, right?

8. What is the risk budget?

And the same for risk budgets!

9. Does the project cost include all of the non-IT costs?

This is relevant when there is a large IT element, or it’s an “IT project”. Training, temporary office space, staffing costs: they all mount up and might not be covered by the IT budget.

10. Does the NPV include all the operating costs?

See if the business case calculations include licences, infrastructure and staff costs as well.

Find out more about NPV in this video.

11. Is the discount rate visible?

And Gary adds: does it reflect the risk of the project? This might be defaulted into the calculations that sit behind the business case but you can at least check that they’ve used the standard calculations and didn’t feel the need to bespoke the maths in anyway.

12. What are the comparators that were used to calculate the discount rate?

Again, this is a good question but might be something set by the Finance team in the spreadsheets used for the business case template.

13. Is the time horizon used for NPV realistic?

 A high NPV is better and NPV generally is used to help show which project is more valuable to the organisation. That comparison is really only valid if you are all comparing projects over the same time horizon. Or if you aren’t, that it’s clearly different and realistic.

14. Are the performance criteria realistic?

Check that the performance criteria are something that you can sign up to. Is this what you thought you would be measured on and do you believe you can achieve it?

15. What risks are missing?

There’s nearly always something missing! That happens because you are a fresh pair of eyes and you’ve just combed through the business case looking for mistakes. There might be risks that jump out at you by their absence but you may also want to discuss the project business case with the team and check that the risks they raised made it into the document.

16. What key assumptions are missing?

And the same for assumptions. You may spot some because you are coming to the business case fresh, and ask the team what they had that perhaps didn’t make it to final version.

In this video I look at 5 costs that you might not immediately think of but that could have a drastic impact on the profitability of your project.

I've been thinking a lot about resource management recently, and I put together this infographic-esque breakdown of 5 of the reasons you really need a resource management strategy on your projects. There are more than 5 reasons, but I couldn't fit them on! For another couple, check out this article.

I often hear that it’s too expensive, bothersome or simply pointless to introduce project management into small companies.

Owning a small company myself, I know that is categorically not true. When you have limited time, limited resources and above all limited funding, you absolutely need to be confident that you are investing them in the right initiatives.

OK, I don’t call everything that I do in my company a ‘project’ because it’s just what I do when I turn up to work. But I do have a plan, a task list, goals and – new this year in my growing firm – a colleague who uses the same project management software as I do so that we stay on the same page.

So I was delighted to get a copy of Gren Gale’s Project Management for SME’s.

The premise of the book is good. Gren writes:

To deliver a high-quality product to time and budget requires leadership, skill and – as importantly – demands that your whole business is set up to support delivery.

There is a lot of good common sense advice: the kind that isn’t common everywhere such as why you should let your team set estimates (because if you don’t, they’ll end up not believing the schedule).

The book is organised to take you through the project life cycle. Each phase is a chapter starting with inputs, actions and outputs. Once you’ve got through the life cycle, Gren covers governance and soft skills.

At the end of the book are helpful document layouts and links to free online versions, which makes it easy to put any of this advice into practice and get started quickly – important factors for small businesses making the decision to move to a formal project management approach.

There are recommendations for software that work well for small firms, which might end up dating the book in the future. Overall, it’s angled towards service and client organisations: the kind of small businesses that run as consultancies or agencies and important points related to what it is like to work in those businesses are called out when it’s relevant.

There are some interesting stories shared that really point to the fact that the author knows his stuff. He’s definitely been there and done that and knows what works in real life.

Having said that, the book isn’t without problems. PMP, for example, is not a methodology but it’s referenced as one quite early on. I know that many PMI members and others would probably just use ‘PMP’ as shorthand for ‘the way PMI recommends projects are run using the PMBOK® Guide as a reference’ but it might confuse someone else who is newer to this whole project management thing.

Equally, I missed the references. The CHAOS report is cited but there is no reference to which year. The original report is now extremely old and not something that is worth citing any longer (in my opinion) as a reference to how things are today. But there have been other CHAOS studies. It’s not clear which one Gren is referring to, which is a shame.

It’s a slim book, easy to read, and convincingly makes the case for why project management should be adopted by small and medium-sized businesses. There’s a clear return on investment, and this book will help you make the case to your colleagues.