The Money Files

by
A blog that looks at all aspects of project and program finances from budgets and accounting to getting a pay rise and managing contracts.

About this Blog

RSS

Recent Posts

What’s New in Project Resource Management (pt 6: Control Resources)

3 Soft Project Benefits [Video]

The Estimating Life Cycle

3 More Ways to Track Schedule Performance [Video]

What’s New in Project Resource Management (pt 5: Manage Team)

5 Tips for Better Decision Making [Infographic]

Categories: tips

When decision making falls on your shoulders, you need to be able to step up and make the decision quickly! Here are 5 tips for making better decisions.

You can read more about some of the ideas on this infographic in this article.

Posted on: June 22, 2018 08:59 AM | Permalink | Comments (16)

Struggle With Stats? You’re Not Alone

Categories: success factors, tips

Wyzant (say: Wise Ant, I think), a marketplace that matches up tutors and students for in-person and online study sessions, has done some research into how people feel about working with numbers.

They surveyed 235 students who recently struggled with statistics. Only 5.5% of these students were pursuing a career in a maths-related field, and many called out business or project management as a potential career path.

That’s a lot of people who don’t intend to use maths as their ‘full time’ day job who are using statistics as part of their course and possibly their future job. Nearly 45% of the students said, “I’m not a maths person,” which is the answer I would have given too. If you hold that view about yourself, you’re creating more stress, anxiety and mystery around the basics of statistics.

What People Struggle With

70% of all the students struggled with the same two statistics concepts, hypothesis testing and probability. 

Personally I don’t use hypothesis testing in my project management work, but I’m sure understanding it is essential in some industries. It hasn’t been since university that I’ve had to think about hypotheses, thankfully. My days of having to understand T-tests and ANOVA are hopefully long gone… if I ever truly understood them at all.

Probability, though – we’re all exposed to that as a function of risk management. It’s often so simplified though that risk assessments are subjective: “I think that my risk is not likely, likely, quite likely, almost definitely going to happen.”

Understanding Probability

Wyzant worked with expert tutors in the field of statistics to identify the concepts and break them down in ways we can all understand. The article quotes PhD candidate, Brian, who tutors university students in stats:

“Typically, when students are introduced to the normal distribution, they’re given a curve and told probability is the area under the curve. But this is still confusing.”

He says it’s easier to think of probability if you break up the area under the curve into 100 squares, each equal in size.

“If you can look at the distribution and say each of these squares is equal to 1% probability, you can just count the squares to develop good intuition about what the normal distribution is and what it means.”

Image credit: Wyzant

I can see how thinking about probability in this way would make it clearer. The bell curve of a normal distribution is all well and good but blocks really call out the way that the 100% is made up and how it spreads out across the distribution.

What do you think?

The website has some helpful guides for common statistics and probability concepts as well.

You might also find this book interesting: Math for Grownups. I certainly found it helpful!

Posted on: July 18, 2017 07:59 AM | Permalink | Comments (4)

How to demo your project deliverables

Categories: tips

Demos and prototypes save your project time and money because you can get early feedback. I’ve talked about that before (in this video) but a couple of people have asked me for some more tips around setting up demos. And I’m very happy to oblige.

Let’s get on with it then, shall we?

The demo environment

Pick a nice room. By that I mean one that is large enough to fit everyone in comfortably and that’s got enough power sockets. Everyone brings a device along these days and they all need plugging in.

Understand the room’s heating and lighting controls. You don’t want people getting fidgety because they forgot their jacket – you want them concentrating on your amazing project deliverable.

If you are doing your demo via a web conference, get the software set up well before you expect everyone else to join the call. Test your microphone and headset and make sure you can share control of the screen with your co-presenters, if you have any.

Set expectations

Manage the expectations of the people in the room. Are you showing them a very rough outline of a product, a prototype that doesn’t quite work properly yet, a feature-rich almost-finished product, or the final thing? Set their expectations around what they are going to see so they aren’t disappointed when features don’t work or when you tell them it’s too late to change the colour because you’ve already ordered 30,000 in blue.

Review your objectives

What is it that you want people to get out of this demo? You can organise a demo or show people a prototype for a number of reasons such as:

  • To get buy in for your proposal
  • To ensure you are on the right track
  • To get feedback
  • To confirm your understanding of requirements
  • To keep your stakeholders engaged on the project
  • To show someone a finished product prior to delivering testing on how to use it.

Think carefully about why you want to do this demo and what outputs you are expecting. Do your demo attendees have the same understanding as you? It’s worth running through the objectives at the start of the meeting, just in case they don’t.

Get organised

Practice, practice, practice. A complete dry run is a good idea. You want your audience to notice what you are saying, not get cut off halfway through your web conference because you don’t know how to use the meeting controls.

Walk through the demo in preparation, whether you are doing it in front of a ‘live’ audience or via a computer screen.

Prepare for questions

Be ready to answer questions. You are showing them your project deliverable in anticipation of some kind of feedback so expect them to have questions about what it does, how it does that and what else it could do. Be prepared to manage the ‘wouldn’t it be great if…’ type questions if you aren’t able to consider any modifications at this point.

Provide back up materials

Your demo attendees will hopefully be so excited about what you have built that they will want to share it with their teams. Have some materials ready so that they can do that: screenshots or handouts are great, but a test login (if software) or samples (if something else) and details of how to use it are better.

This gives them the chance to play with what you have created and if you want further feedback, let them know that you are open to their ideas and provide details of how to get them to you – direct contact, via an online request form or so on.

Demos and prototypes are a really powerful tool, especially if you are delivering a software product or a tangible item. End users particularly find this sort of workshop or meeting a very valuable session as they can see what they are getting. In my experience, showing someone a demo of your product helps build engagement too, as they start to get excited and they can see the idea become real.

However, make sure that if you are doing a demo that you are in a position to comment about when they are likely to get to access the final deliverable. There’s nothing worse than seeing a demo and getting excited about the project only to be told, or you can’t have it for 18 months. Set expectations carefully!

How have you used prototypes and demos? Let us know in the comments.

 

Elizabeth Harrin also blogs at A Girl’s Guide to Project Management.

Posted on: October 11, 2014 06:12 AM | Permalink | Comments (0)

Get the most out of a conference (video)

Categories: tips, video

In this video I share 4 tips to help you get the best out of attending a project management conference.
Posted on: September 26, 2014 08:41 AM | Permalink | Comments (0)

How to read a bridge (and use one on your project)

Categories: methods, reports, tips

A bridge is a way of displaying financial information in visual format. You might also know it is as a waterfall chart, or ‘the one with the flying bricks that looks like something from Mario’. It’s just a way of showing how an initial position has been affected by subsequent changes, so you can see why that would be useful for a company’s financial position. It can show changes that are positive and changes that are negative, and ends up with the new cumulative position as you can see in this diagram.

This picture shows a completely made up scenario, but I think it illustrates a point. In September, the starting position for this department was $75,000. This could represent value, profit or anything else. Then there were some things that changed. These are illustrated by the small floating boxes: the first change that happened was a positive improvement of $16,000. Then there were some other criteria, inputs and changes that also increased the situation positively.

Now we come to the black boxes. These on my chart represent money out, so let’s say this department spent $2,000 on some new software licences and $1,000 on a big party for everyone. This has had an impact on the net position so if my maths is right, the closing position on the graph, the situation in October, is now $100,000.

Great. But how is this relevant to projects?

Typically this type of bridge is used to represent financial information and you have financial information on your project, don’t you? I think it is a great way to present the impact of changes on your project budget to stakeholders. It’s useful because it’s a good visual representation of how you got from there to here and where the money went.

So you could use it to show the financial changes on your project, but there is nothing to stop you using the same layout to display other sorts of changes. Take this version, for example.

This shows you the situation in September in terms of project days. There are 150 days allocated to this project. Then there are a number of changes put forward. The green boxes show what would happen if you add those changes – the number of days spent on the project goes up (it’s not rocket science really). There are also some changes that save you time on the project. Let’s say that the big one, the 20 day time saving, is because the project sponsor has decided that the overseas office isn’t going to be included in this initiative after all, so there is no need to train those team members and you can save a whole lot of time. Another little change knocks 3 days off your project total.

If all these changes are approved, your project will now take 152 days.

When you are looking at individual changes at the change board, some stakeholders might find it hard to keep approving changes that add time. Two changes that add 10 days each? That’s huge. But when they see all the changes on the table that month laid out like this they can see that approving them all only adds 2 days to the project overall. That’s a very different story.

Of course, you might not want all those changes approved – there might be some stupid suggestions in there or functionality that would be better pushed off to a Phase 2. But using this bridge diagram gives you a new way to present the same data to stakeholders and help them decide on the impact overall.

I hope you find it useful!

Posted on: September 16, 2014 05:20 AM | Permalink | Comments (1)
ADVERTISEMENTS

"I don't like work - no man does - but I like what is in the work - the chance to find yourself."

- Joseph Conrad

ADVERTISEMENT

Sponsors