The Money Files

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.

Define ‘done’

“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.

One of my videos for this blog was about the 3 steps for prototyping. But what if you can’t prototype, or choose not to? Today I want to consider what alternatives you have.

Pretotyping

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.

Beta versions

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.

Experiments

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.

The Gartner PPM and IT Governance Summit was held in London last week. Lars Mieritz, a Gartner analyst, gave a good presentation about using metrics for communicating project success and effectiveness. He started out by saying that the top concerns of C-level executives and their direct reports, based on their research, were:

• Demonstrating PMO value
• Effective reporting and executive dashboards
• Measuring the business value of projects, programmes, and portfolios.

Gartner has many years of research in this area and he shared an interesting trend: in 2003 the top concern of CIOs with regards to IT strategy was the need to improve governance and provide leadership. In 2013 the top concern was delivering business solutions. There’s been a shift towards integrating IT more effectively with the rest of the business.

Why metrics count

Project management metrics based around portfolio performance help improve the perception of success. When researchers asked people what they thought of their PMO the views were pretty poor:

• 29% said they got some value out of the PMO but it was largely bureaucratic
• 33% said it was an integral part of getting things done
• 28% said it was a useful admin/support function.

As Lars said, he hasn’t spend decades in PPM only to be considered a useful admin function, so it’s clear that PMO customers believe there is certainly room for improvement in the services the PMO provides.

KPIs, said the verbatim comments that formed part of the feedback of this study, don’t link to business strategies. They don’t talk about shareholder value. Metrics relating to output don’t explain how to improve this output. Metrics don’t identify or clarify issues relating to performance. And finally, business management teams can’t relate to technical measures.

So, PMOs have plenty of metrics, but PMO customers don’t understand them or think they are useful. What should we be doing instead?

Creating good metrics

The main takeaway for me from this section of the presentation was that you shouldn’t copy someone else’s dashboard. What works for one business isn’t going to work for another, so templates aren’t actually that useful here. Every PMO is unique and provides a variety of bespoke functions to the rest of the organisation, so you should tailor the reporting and metrics in use to reflect that.

Metrics, Lars said, should reflect a strong customer focus to ensure they are well-understood and take a business view of project success. How is success viewed? he asked. Then shape management communications (i.e. reporting and metrics) along those lines. He offered some questions to ask yourself when putting together the relevant metrics for your PMO:

Is there organisational acceptance for standardisation around a single approach or method of reporting? This is particularly relevant if different business units have built their own measures and techniques over time or due to mergers and acquisitions. Different techniques mean different results.

Are the definitions of KPIs and metrics simple and useful for external comparisons? Even if you don’t need to compare performance of your PMO and projects with other companies right now you can be that someone will ask you to benchmark performance at some point in the future. Make your life easy and prepare for that now.

• Can you use data from other departments to save reinventing the wheel?
• Is all the underlying data readily available and more importantly, credible?
• Does everyone understand why you are gathering metrics and the purpose and objectives of this initiative?
• Are there sufficient resources to put together a full, comprehensive metrics plan? Do you have enough people or budget to support any training required?
• Is there senior management buy in? Setting up metrics is, after all, a project and it needs executive sponsorship.

Implementing project metrics

Once you’ve defined what metrics are relevant for your PMO, you then have to go ahead and implement them. Lars recommended engaging with users to ensure they understand the process and how these metrics will help improve things. For example:

• Average time lag between identifying an issue and corrective action – shows you delays in addressing problems and then you can work on speeding this up.
• % of projects with complete documentation – shows you where projects might be at risk due to information not being gathered; identifies project managers who many need additional support.
• % of projects with a status report over 10 days old – shows you where project data is out of date and who needs a kick to remind them to update it.
• % of total effort required to reach end of first phase – shows you potential for project to deliver on time and accuracy of planning/estimates.

“Good dashboards show where the problems are,” he said. And that gives you the chance to show what you are doing to eliminate the problems.

Dashboards should track what is important. He also had a great recommendation for PMO leaders who have to produce short reports for their colleagues or sponsors: if you don’t have much time to present statistics (or many pages to present on) then cycle round the metrics you show each time. For example, average number of training days per project manager won’t change much from month to month so show this one month and then report on something else next month. Over time it will give you the chance to report on more metrics, and of course if someone wants to see the training days figures they can always ask for them.

In summary, Lars concluded that metrics should enable us to take action, otherwise what’s the point of them? He said that we should seek metrics that are simple, intuitive and focus on goals and that finally metrics don’t replace judgement. You’ll always have to apply your contextual knowledge to a dashboard to interpret the full situation.

I attended the Summit as a guest of Genius Project.

How do you know if your project is going well? Schedule performance is a reliable way of assessing whether you are on track or not. Here are 6 ways to review your schedule performance and see if you are making the progress you expected.

1. Earned Value

Earned Value management is probably the most reliable way to track and manage schedule performance, but it’s also quite complex to get right, especially if you have no prior experience of working in an EV environment. On a small project you might find that a full EV approach is overkill.

However, it is a good discipline so if you have the time to set it up properly and feel it would be beneficial in your project environment, then you’ll get accurate and useful results with it.

2. RAG/RYG Indicators

Managing through simple colour-coding is pretty basic, but many senior executives like this as it helps them see which projects in a portfolio need their attention. Projects that are coded Red or Amber/Yellow need management attention, and those that are Green don’t.

To add an extra level of data to this simple scheme, you can flag trends with arrows. If the project is green at the moment but at risk of sliding into the Yellow zone, include a downwards arrow in the status information, for example.

You do need to set definitions for what each colour means. This will help avoid the situation where one project manager thinks a project is performing well and another would report the same situation as needing management attention, so set your criteria (or check what your PMO has already set) before your project starts.

3. Progress against milestones

Schedule progress is easy to measure against milestone data. List the milestones that should have been achieved during this reporting period and note whether they were hit or not. This gives a really visual, simple way of showing if the schedule is on track.

If a milestone has not been achieved by the target date you should also include a revised forecast so you have an idea of when it will be completed by.

4. Team morale

This is a measure that was flagged to me by Healthcare Project Management, a book by Kathy Schwalbe and Dan Furlong. I hadn’t considered this before, but team morale does have an impact on schedule performance. They write: “If project team members are always working extra hours, the schedule might not be realistic… On the other hand, if workers are coming in late and leaving early while still producing quality work on time, the schedule might not be challenging enough.”

A happy team may work extra hours because they believe in the project and love what they are doing. Or they might be doing the extra hours because they are swamped with work and couldn’t cope otherwise (in which case you should watch for burn out as they won’t be able to sustain that for long).

5. Tracking Gantt chart

If you use your Gantt chart software to generate baselines and show actual start and finish dates you can generate a tracking Gantt. This will show you progress against your original forecast and is a visual way to display schedule performance. You can generate all sorts of views of this information so you can get a good understanding of which tasks are underperforming. This is easy and useful, so use baselines if you can.

6. Status review meetings

Finally, you have the option of reviewing schedule performance in person (or as part of a virtual team meeting) with the rest of your team as part of a status review session. Trusted team members will give you their impression of how the project is progressing and whether or not they are performing as per the forecasted scheduled work.

Combining this narrative report with data from your project management systems will give you the best overall view of schedule performance. After all, you can’t use data successfully without understanding the context, so it will help to have your team members discuss project status with the figures in front of them.

Understanding schedule performance is critical if you want to bring your project in on time. When you know how your project is performing, you can make changes as appropriate to bring it back on track or enable the continuation of the good work.