5 Steps for Make or Buy Analysis (video)
8 Tips for better benefits management
You’ve got a great project with a ton of benefits coming your way. Everyone’s really happy. And then someone says: “Exactly how much are we going to get from this project?” Suddenly it’s no longer enough just to list benefits – you have to quantify them as well, and that means producing an accurate forecast. Ouch.
So what can you do to get that benefits forecast as accurate as possible? Here are some tips for building a more reliable outlook.
1. Strong leadership
This almost goes without saying. If you have your project sponsor encouraging you to be transparent and honest with the estimating process, challenging your assumptions and leading by example then you will get a better result.
2. Validate first
Don’t invent a way of measuring benefits (when they are realised) that you can’t test. Test your benefits capture mechanisms, and then change them when they don’t work the way you thought they would!
3. Account for them now
People are more inclined to produce accurate forecasts if they know they will be held to account. If you expect your project to deliver a certain financial benefit, put that in the right department’s budget today. If it’s a productivity benefit, build that into the team’s annual objectives or performance targets.
4. Be negative
Take the opposing view to challenge estimates. Think critically about the other side of the argument and what would happen if the benefits aren’t delivered as planned. This can help you avoid optimism bias and come up with a realistic range.
5. Get another opinion
Pick a trusted project management colleague or even someone in a different team to review your estimates. This independent challenge can give you another perspective and help you avoid getting sucked into a project team mentality in which you make unrealistic assumptions. An internal auditor could carry out this role for you, or someone from your PMO.
6. Don’t estimate alone
Use the Delphi technique or other group estimating tools – you’ll get a far better, more accurate result than if you came up with the benefits forecast by yourself.
7. Forecast a range
As with financial forecasts, predicting an amount in a range gives you more flexibility. Avoid single-point forecasts (“We’ll generate $689.52 extra revenue”) and opt for a spread of figures (“We’ll bring in between $550 and $700 in extra revenue”).
8. Review your estimates regularly
As your project progresses, go back to those estimate and make sure that they are still accurate. Your project will change and those changes could well have an impact – positive or negative – on the benefits forecast. Keep your forecast up to date and communicate any changes to the key stakeholders. A change too far in the wrong direction could mean your project is no longer viable. Linking back to the first point on this list, that’s the time when strong leadership comes into its own. It might mean cancelling the project or backing out some changes that have an adverse effect on the benefits profile.
Benefits are the reasons we do projects and programmes, so if the benefits aren’t there, you have to have a very good justification for continuing to work on the project. That’s why benefits realisation is important. More effective benefits realisation happens when estimates are good, people understand how they have been calculated and above all, they are realistic. It isn’t hard to do, but more often than not project teams and the organisations they work for don’t spend the time on the benefits planning stages to get good results at the end.
What does your company do? Let us know in the comments below.
5 Ways to make better decisions
Projects need lots of decisions and often it can take a long time to get a decision made, especially if there are numerous levels of bureaucracy to get through. Time is money on many projects, and while I don’t often come across project teams sitting around waiting for a decision before they can move it forward, I am aware of several projects where stalled decisions have impacted delivery dates and tasks on the critical path.
Speedy decision making relies on people actually thinking the problem through, gathering data and coming to the decision – and, of course, speedy decisions are not always the best decisions.
When the decision is under your control, you’ll have to make it. How can you be better at decision-making? Here are 5 tips to help.
1. Consider the long view
Think forward: what decision would you wish you had made next month? Next year? In five years? Approving overtime might feel like the right thing to do now but how will you feel about it on your next project when you’ve already set the precedent and the team are expecting to be paid for extra hours?
Think about the long view as it relates to your decision. This will also help you put the decision in perspective. Remember back to when you took your school exams. I expect the results meant a great deal to you then, but you probably don’t even put them on your resumé any longer. The significance of actions changes with the passing of time, so think about how you’ll feel about this decision in 10 years – you’ll probably realise that it isn’t that big a deal after all.
2. Cut out data
What data do you really need to make this decision? Strip away everything else. It might be nice to know the resource allocations for the next month, but if that doesn’t have a bearing on whether you accept a schedule change or not then they shouldn’t be taken into account.
Make sure that you are using the right data, not any data to make your decisions, and go for the minimum possible. This will help cut the mental clutter and make it easier for you to see what needs to be done.
3. Understand the impact
What’s the impact of this decision? What will happen if you don’t make it? Sometimes understanding the ramifications of a quick/slow/positive/negative decision can help you tackle it effectively (or at least gather the right information to help).
I’ve often found that the larger the impact, the easier it is to make the decision. Sometimes small decisions seem the hardest because there tends to be less clarity about the appropriate route forward.
4. Lose the emotion
We all get attached to our projects and teams but it is best to take the emotion out of decision-making. Think about what is best for the project and the company. For example, it might be an unpopular decision to reject a change from the Marketing department, but if it doesn’t help the project meet its objectives and it costs a lot of money, then it isn’t a smart thing to recommend to your sponsor. After all, your sponsor can choose to accept or reject it – you are just putting forward an emotion-free assessment of the change.
5. Intuition isn’t always right
Many project managers report ‘going with their gut’ when it comes to making decisions or working out how to resolve problems on projects. However, the application of some technique does have benefits. Your intuition isn’t always right – ever been caught out in the rain because you figured it would be dry all day so no need for an umbrella? You can’t rely on your gut when project dollars are at stake.
Choose the right data to support your decision. By all means include some ‘gut’ in your decision-making process but be able to back it up in case anyone asks you why you’ve made that choice.
What decision-making tips and techniques do you use, or do you tend to simply go with what feels right? Let us know in the comments.
Creating a stellar delivery organisation
At the Gartner PPM & IT Governance Summit last month Donna Fitzgerald gave a presentation about the factors that go to support a stellar delivery organisation. That’s a fancy way of saying getting your project management maturity levels up so you have a better chance of project success every time.
The Gartner PPM maturity level model includes 5 levels of maturity but Donna said very few clients make it Level 5. “Life at Level 2,” she said, “is no longer good enough. Many organisations are facing the crash and burn. They are operating in a perfectly acceptable paradigm for yesterday.”
The jump for Level 2 to Level 3 is what Donna called ‘crossing the chasm’. It’s the difference between process controls, governance and management and balancing capabilities and delivering measurable business value. That is quite a leap.
Don’t project manage everything
One of my top takeaways from Donna’s presentation was the fact that you don’t need a project manager for everything. Too often I see little projects managed by project managers when the development team or a business team could have managed it perfectly well by themselves (and 10 years ago did exactly that). If you want to do more with the skilled project resources that you have, stop asking them to work on business as usual projects that other teams can handle. “For optimal project success you want the work done in less than 6 months and full time staff of 5 for a half-time project manager,” she said. Project management deals with the uncertain, risky and complicated, she concluded, so if your project isn’t like that, then it doesn’t need a project manager.
If you do have a half-time project manager on the team she recommended time boxing their commitment. It’s now commonly believed that multi-tasking is bad and that humans aren’t very good at switching between tasks. Therefore if you are scheduled to work 50% of your time on one project and 50% on another project, make it so. Work Monday, Tuesday and Wednesday morning on one project and the rest of the week on the other. Don’t try to do both at the same time. A consulting firm wouldn’t expect someone to jump between assignments with an hour here, an hour there, she explained, so you can make fixed time allotments work.
I’m sure you can, but it’s going to be a mindset change for the workplaces I’ve experienced. Project queries and stakeholder phone calls don’t stop because it’s a Thursday.
“Done,” Donna said, “means the short list of things that define the business capability [being delivered by the project].” This is not the requirements document as that document is really a contract with an external supplier, she said. I would argue that it’s also often a document for internal supplier teams to work from and while you’re not likely to sue the team that sits on the other side of the office to you, there is a chance that you’ll use the requirements document as a basis to sue a vendor for failed delivery.
Define ‘done’ with your project team and sponsors so that you’ll know when you get there and you can work towards achieving that.
Don’t start without committed stakeholders
This was another major takeaway for me. Donna is ruthless! She said we shouldn’t start a project without committed stakeholders. She said that if they don’t turn up to the initial meetings (as sometimes happens) then don’t be afraid to ‘throw them under the bus’.
Say: “I’m sorry, I didn’t realise this was a bad time to start this project. We’ll reschedule.” And leave the meeting room or their office. Sometimes you’ll come across stakeholders who genuinely aren’t able to support the project right now and that’s OK. Reschedule project initiation for a time when they can commit. But sometimes people are just lazy or unclear on their responsibilities or happy to delegate everything to you and take no role in their project at all, and that’s where the bus comes in.
Make time to reflect
Part of delivering a stellar project organisation is knowing that things need tweaking. And with the stresses of managing projects it is unlikely that you, as a PMO Manager or even as a project manager thinking about your own project culture, have time to do that.
Make time was Donna’s recommendation. “Nothing ever gets fixed if you don’t realise it’s not working,” she said.
Book two afternoons per month to get away from your desk and think. Start with saying, where am I, where are we, what’s the health of my projects, what’s bothering me. Sometimes you can’t see patterns in behaviour because you are too close to them day-to-day so this gives you the opportunity to reflect and objectively assess what is going on.
She recommended we spend 20% of our time talking to sponsors and extended stakeholders as this is good for careers, and it’s what successful PMO Managers do. I don’t think I do that, but it’s certainly something I would like to focus on.
These were the top tips I took away from Donna’s very practical presentation. I hope they help you!
You can follow Donna Fitzgerald on Twitter @nimblepm.
I attended the Gartner Summit as a guest of Genius Project.
Alternatives to prototyping
I came across this in the essay by Melanie Rose in the book Business Analysis & Leadership. She explains the difference between prototyping and pretotyping:
“Pretotyping differs from prototyping in that the main objective of prototyping is to answer questions related to building the product: Can we build it? Will it work as expected? How much will it cost to build? The purpose of pretotyping is to answer questions about the product’s appeal and usage: Would people want this product? Will they use it as expected? Will they continue to use it?”
You still have to create something for people to comment on, but it’s often a much cheaper version than a prototype because the aim is to judge appeal, not to see how it would work in practice. If you know there is a market for your product you can then work on prototyping something. If you find that there isn’t much interest in your idea then you haven’t lost much of an investment.
Many software products are launched as beta versions: not quite the finished product but near enough. Users can either choose to wait for the full, finished release or become beta testers with the expectation that they will report errors, provide feedback and generally help the company test the end product through actual use.
I’ve been a beta tester before and it wasn’t a huge overhead. In fact, many beta testers are often offered discounted rates on the final product and this helps turn them into very loyal users.
Could you set up an experiment in a controlled environment to test your product before it goes to market? Consider it a bit like Monte Carlo analysis but for deliverables instead of risk. You could get users involved. Choose something concrete to test if you go down this route – it isn’t going to work for all projects.
Using your ‘fans’
If you are upgrading a software product or service that already has a dedicated user base you can tap into these people and offer them the chance to take part in a trial. Whereas beta versions are generally open to anyone (and some beta versions become the default so you have to opt out of using them), ‘fans’ are a self-selected group. Stick a notice on your website, or email your highest-traffic users.
The benefit of tapping into your existing base of enthusiastic users is that they can be very forgiving and keen to report errors as they already love your product and are invested in it. Again, this isn’t going to work for all projects, but it is particularly relevant in the IT arena.
Prototyping is a great way to test a product prior to moving into final development phase, but you do have other options (or options you can use as well as prototyping). Have you tried any of these? How did they work for you? Let us know in the comments.