The Money Files

Strategic thinking is one of those skills that gets tossed around as something project managers should have. But how can you be more strategic in a practical way? I’ve been thinking a lot about this recently, and here are 3 things I think you can do as a project manager or leader of a project delivery function to try to bring more of the ‘strategic’ into the way you work.

1. Get involved with business cases and proposals

First, lobby to get involved with business cases and proposals. The more delivery expertise we have involved in the initial stages of a project, the more likely it is that the project will be able to actually hit its goals.

Have you ever been involved with a project where you’ve been handed something to do and the sales people have made promises that you can’t deliver on? Then you’ll know what I mean!

When project people are involved in business cases, in my experience you’re more likely to end up with a timescale that’s achievable and a resource plan that reflects the real amount of resources likely to be consumed by the work.

It’s even better if you can lobby for a seat at the table when the 3-year plans are being drawn up, so your top level project people, like the Head of PMO, get involved in creating the strategy in the first place. That provides a real insight into what initiatives are coming and how the delivery teams can help.

2. Use the project assurance function as a check mechanism

Project assurance is a way of checking that what you think you can do is actually achievable. It’s their job to pick apart your plans and proposals and apply a sense of real-world pragmatism. They can also help identify whether there are any resource gaps, strategic holes or other issues that you haven’t seen.

After all, as a project manager I’m sometimes so close to the information that I can’t see the bigger picture enough to realise that this project will clash with something that someone else is working on – but project assurance has the bigger picture and can point that out.

If you don’t have a project assurance function, ask a colleague for their opinion and talk them through the plans, asking them to basically pull them apart. Ideally, to be able to add some strategic oversight to your plans, this should happen around the time of the business case or PID. By the time you’ve got to creating a schedule you’ll be looking for a different kind of peer review.

3. Share what you know – but only what you know

My third tip is something I learned from Tony Meggs, Chief Executive of the Infrastructure and Projects Authority in quite an old article now that he wrote for Project magazine, but it has stuck with me. He said: Only announce what you know.

We know this in theory, so it’s not news to you, I’m sure. However, many project managers are ‘encouraged’ to share dates before we are ready, or pushed into committing to dates publicly before we have all the information to support the fact we can deliver to them.

So, if you want to be a strategic operator, only share what you know to be achievable. That goes for delivery methodologies as well. Meggs talked in the article about not committing to anything unless you know it to be true, including how the work would be delivered. If you are going to partner with someone and there’s a robust contract in place, by all means announce it. But don’t announce your intentions before they are fixed in stone because if it doesn’t happen you’re then having to walk back on the messaging and that can be damaging.

We can do this as project managers on a small scale, by giving our teams the space to come up with the best methods and timescales before we announce them to sponsors, but also on a strategic level, by ensuring there is a communications plan in place that supports the bigger picture messaging for the project, programme or even the portfolio.

Do you do any of these already? How are they working out for you? Let us know in the comments!

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.

How did you do with sticking to your resolutions from last year? If you are anything like me, you would have started out with good intentions and then forgotten all about them as the snow melted.

This year it's not too late to make some resolutions about managing your projects more effectively, and make them achievable so you’ll actually stick to them throughout 2014. There’s no point in setting yourself unrealistic targets, so let’s look at some project management resolutions that you could still be doing next December.

1. I will do timesheets (and get my team to do the same)

If you don’t use timesheets already, make 2014 the year that you start. They are essential for finding out where your time is actually being spent, and you can use the data for loads of things including improving your estimates.

Do them regularly and you’ll find that you aren’t blocking out 7 hours per day to a bucket task called ‘project management’. You’ll get the granularity of detail required to understand exactly what your project management effort is being spent on – reporting, budgeting, team management and so on. And then you can assess whether that’s reasonable or not.

Break down your resolution into manageable chunks such as:

• Quarter 1: Select project management timesheet application
• Quarter 2: Implement application and train staff
• Quarter 3: Bedding in time, we all start using it
• Quarter 4: Aim for timesheets to become business as usual.

2. I will understand what the Finance team actually does

How much do you rely on your company’s Finance team to help you understand and manage your project budget? They are the experts about your business’ financial processes, forecasting and managing budgets, so you may as well use them. On some projects, you may have a financial analyst allocated to the project team on a full or part time basis too.

Here are some videos to help you get started understanding the role of the different Finance teams:

• Treasury team: http://www.projectmanagement.com/blog/The-Money-Files/6144/
• Accounts Receivable: http://www.projectmanagement.com/blog/The-Money-Files/6108/
• General Accountants: http://www.projectmanagement.com/blog/The-Money-Files/6034/
• Accounts Payable: http://www.projectmanagement.com/blog/The-Money-Files/5890/

3. I will improve my estimating

How good is your estimating? If you feel that your project team needs to understand why estimating goes wrong and they could do with a bit of help when it comes to getting their estimates spot on, why not make that the focus for 2014? There’s a lot that you can do to help the people in the team manage the estimating process more effectively, and also estimating tips that you can give them.

Here are some more video resources to review:

• The Estimating Lifecycle: http://www.projectmanagement.com/blog/The-Money-Files/6443/
• Parametric estimating: http://www.projectmanagement.com/blog/The-Money-Files/6343/
• Analogous estimating: http://www.projectmanagement.com/blog/The-Money-Files/6231/
• Bottom up estimating: http://www.projectmanagement.com/blog/The-Money-Files/6567/
• Team roles in project estimating: http://www.projectmanagement.com/blog/The-Money-Files/6672/

4. I will include financial updates in my reports

Project status reports don’t always include a section on finances. This could be because your project sponsor isn’t that interested, or because you are sharing the information with people with whom it wouldn’t be appropriate to discuss the project finances with. But if your reports don’t include a budget update, you should be clear why this is – don’t just leave it out because it’s too hard or because you don’t know what to include.

Talk to your sponsor about what he or she would like to see in your status report and provide budget updates as required on at least a quarterly basis.

5. I will quantify the cost of risks

Does your project risk log include the financial impact of risks? Many don’t, because many risks aren’t quantified like this (or at least, many project teams don’t bother to quantify them like this). Of course, quantifying your risks in a financial way may not be appropriate for all the risks on your log. There are probably some risks that affect the project in ways that will not have a financial impact, or where you’ll be trying to calculate the financial impact based on some arbitrary figures.

But there will be a financial cost for many project risks. This is either the cost of the risk occurring or the cost of the mitigation plan – either way you can calculate the impact and then add this to your project budget so that you are clear about what implications the risk has on your financial planning for the project.

Will you use any of these as your resolutions for 2014? If not, what are you having as your resolutions instead (if any)?

Elizabeth Harrin is Director of The Otobos Group, a project management communications consultancy. Find her on Facebook.

The theme this month on Gantthead is personal project management: how we keep our own personal projects on track and organise our work. Here are some ways I manage this.

Action lists

I don’t use a PDA, or the task list in Outlook, or an online to do list app. I use paper. Lots of it. I have a notebook for my project – luckily I’m only working on one major project at the moment. If I wasn’t, I would still have just one notebook, with all project notes in it.

I take notes at the front, and any actions that need doing are marked in the margin with an A in a circle. That makes it easy to scan the page and see what is a record of the meeting and what is something that needs action.

At the end of the meeting, or when it is getting too confusing to flip through the pages, I copy all the actions to the back of the notebook, so that becomes my to do list for everything.

Other symbols

I organise my handwritten notes with other symbols as well. I in a circle means an issue – something that needs adding to my issue log. R in a circle means a risk to be added to the risk log. W in a circle is an interesting fact that should go on the project wiki. An asterisk next to an action or any other item means – you guessed it – the item is really important.

It’s not rocket science, but it’s a key that works well for me.

Outlook

It is bad practice to use Outlook (or any email client) as a filing system. It takes up too much disk space and it means your files can’t be shared. The newer versions of Outlook have much better search capability but it still isn’t perfect, so it can be difficult to find what you need again.

I save copies of important emails to the project network drive (File/Save As). I also save attachments to the correct shared location and then the email itself can be deleted. Having said that, I do have a nested filing structure so that I can keep important messages.

I archive the filing structures for old projects so that the emails are saved for a rainy day in case anyone ever needs them for auditing or contract discussions etc. Archiving them means they are not automatically linked to my Inbox and other folders, speeding up the search results and making it easier to navigate through what is actually important right now. If I need to see them again, I can open the archive, and then close it when I’m finished.

Periodically I clear out my Sent items folder. Things that can be deleted include meeting invitations and responses (you can identify these in Outlook by the calendar symbol and you can also sort the Sent items list by that symbol so you can group them all together for easier deleting). I also delete any emails that just say ‘thank you’ or that are general chit chat. Items that are relevant for the long term are filed in the appropriate folder.

My Inbox – that’s where it’s at. My inbox acts as my to do list. Anything in the inbox is to be completed, followed up or actioned in some way.

It is also a way of keeping an eye on what other people are supposed to do. If I send an email to someone asking for something, I move the item from Sent to Inbox so that it is easy to see that I am waiting on a task. Equally, my inbox includes items on which I have just been copied in. There’s no action required from me, but it’s something important to the project so I want to make sure I have visibility of it so that I can follow up.

Those are some tips that work for me at the office. What do you do?

The Gantthead T-shirts are great - and here's the proof! Which one is your favourite?