The Money Files

Risks get logged on our spreadsheets or in our tools, but it’s often the identification part that people find difficult.

Below are 5 causes of risk. You can use these as a jumping off point for your own risk identification. What would happen on your project if one of these causes created a situation for you?

1. Equipment failure

On projects in the past, we’ve had the local council cut through power lines while doing work digging up the road outside one of our locations.

We’ve had internet outages. We’ve had component failure. And once one of my colleagues had their laptop stolen from out of the back of their car – not exactly a failure, but it caused the same kind of situation. If you’ve ever lost a piece of tech you’ll know the headache that comes with getting a new one and all the governance paperwork to fill in too.

What risks could you have on your project around equipment failure?

2. Planning errors

Incorrect estimates, incorrect assumptions… these all lead to the potential for your plans to be wrong.

Even missing out someone’s annual leave or scheduling over a bank holiday because you didn’t have it on your calendar can cause a delay.

You might have risks related to the accuracy of your planning and scheduling.

3. People problems

A lot of project risks are created by people! For example, in one situation I heard of, a project team hired the wrong person for the job. The candidate said they could do the work, it sounded like they could do the work and when they showed up, they couldn’t.

Other risks could be the risk of someone not turning up (as has just happened in our house with contractors due to fit the new floor), refusing to do the work, changing their daily rate or is otherwise demonstrating difficult behaviour.

Even if you can resolve the problem, sorting out challenges like this takes time and energy, and often we don’t have much of that on projects.

What people-related risks can you foresee on your project, and what can you do about them?

4. Watermelon projects

Another risk is that people don’t report the true status to you so you end up with a watermelon project: green on the outside and red in the middle.

You can deal with that risk by making sure you have processes for adequate reporting and are able to understand the current situation. If you don’t have visibility, you can’t control the project.

Could one or more strands of your project be at risk of going watermelon?

5. Miscommunication

Finally – and this can happen on any project – miscommunication. Team members do things wrong because they don’t understand or they haven’t had complete instructions.

In theory, this one should be easy enough to resolve, so much so that you might not even think it is worth putting on the risk register at all. However, if you work with a cross-cultural team, different time zones or remote teams then it is probably a higher risk factor for you.

Would your project be at risk of communication challenges?

Have you found yourself short of time on a project? It’s happened to me more often than I can count – “If only we had a bit more time,” we say, as we hurtle towards the scheduled go live date.

But can you make more time on a project? Kind of. Here are 7 ways to save time on a project.

1. Add resources

The first, easiest, option is to add resources. Bring in more people or equipment so the job gets done faster.

Another option is to add more money to the project: with a larger budget you will have more choices. Perhaps you could opt for faster shipping or buy in an element of the project instead of having to make it yourself. If you’ve got contingency budget or access to a management reserve, can you make the case that it’s appropriate to use those funds in this particular circumstance? Make sure you can justify your ask.

2. Work in person

This one might be controversial, but I think there are time-savings to be made when you bring people together.

Working in the same room saves time on the back and forth of conversations done virtually. If you have critical deadlines, are deep in bug fixing or are supporting a go live, consider getting the project team together for faster results.

3. Review the scope

Review the scope and see what could be done in a smarter way: do you really need a print booklet of the annual report or could you manage with a PDF only? Could you move any activity to a Phase 2?

Changing the scope to save time usually means doing less, so it’s only an option if you can deliver a decent result for your stakeholders by taking shortcuts. Make sure they are onboard with your recommendations and have the final say about what gets cut.

4. Review the schedule

Review the timeline. Look for discretionary dependencies: the ones you can move without it being a huge deal. Put tasks in parallel instead of in sequence but accept the risk that comes with this. You might end up doing work twice or revisiting things that are technically ‘completed’ because working in parallel might throw up some challenges later.

5. Review assumptions

What assumptions have you made that may not actually be true? This is particularly relevant about people’s availability. For example, if you assumed you could not work on site after 6pm because that’s what has always been the case in the past, it is still worth finding out whether you could extend on-site hours for this project. That could save some time.

6. Review the staffing

Can you switch out the apprentice for a more experienced (and therefore faster) colleague? What could be done before the expert gets their hands on it? Perhaps a colleague could draft the test scripts and have the experts in the test team polish them up. That way they don’t have to start from scratch.

This doesn’t always pay off. I know from editing articles from other writers that sometimes the editing is just as time-consuming as writing the whole thing, but it could work in certain circumstances so it is worth considering.

7. Be your best self

Finally, be someone people want to work with. Make sure you invest the time with stakeholders before the challenge of delivering faster arises (I know, you don’t have a crystal ball) so they are prepared to work with you when times are tougher.

You can’t switch this on as a last minute shift around, but approach your project team and all the work you have to do as a kind, professional leader. And you never know, when you ask other people nicely for help, they might just say yes.

The market seems pretty buoyant at the moment for project management jobs: if you remember back, PMI predicted a while ago that the world would need many new project management roles filled to meet demand, and while I don’t have hard facts to back it up, anecdotally there seems to be a fair number of roles around at the moment.

The good news is that many roles maintain an element of remote working, with some vacancies being advertised as fully remote, so location is no longer a constraint when looking for work.

If you are in the market for a new role, and are getting ready to hit the interviews, then here are some tips that might help you impress recruiters and land that premium position.

Read the job advert carefully

I know this seems obvious, but if you go back to the job advert before your interview, you can pick out keywords and skills that they are likely to want you to evidence. The time between application and interview can seem like ages, so keep a copy of the job ad to remind yourself of what you applied for.

Read the person spec and any other info

Go through the person specification or further information about the role like the job description. Again, you probably did this on application to see if you were a good fit for the role. This time, you’re reading for the main skills that are likely to get asked about at interview.

If there are any buzzwords, power skills, notes about past experience, make sure you put some time aside to come up with examples you can talk about during the interview that show you have those skills.

Read up on the company

What can you find out about the company and team you are applying to join? Check sites like Glassdoor, see if any of your connections on LinkedIn work there, check customer reviews for a sense of what is important to them.

Read the annual report, check out their social media presence and watch any videos from the senior executives if any exist in the public domain.

This research is a useful source of information about values, culture and whether the company is a good fit for your future ambition. It’s also helps you come up with questions to ask at the end of the interview, when the interviewer inevitably asks you if you have anything else you’d like to know.

Speaking of which…

Make a list of questions to ask

Come up with three or four questions to ask at the end of the interview. You want a few to choose from in case some of them are answered within the interview discussion itself – if that happens, you might be left with nothing left to ask, and I think it always looks good to have something to say at that point.

Remember, you don’t have to wait until the end to ask. If the conversation drifts on to a topic relevant to your question, ask it then. After all, the interview should be a conversation rather than an interrogation.

Finally, remember that this is your chance to find out if the company is a good fit for you. Taking a job that is not right for your values, work/life balance, skill level or anything else that makes it a bad choice is only going to be something you regret in the future. Possibly in the very near future.

Use the interview as a way of checking that what you have learned about the role and the company holds true, and that you would like to build the next phase of your career there. Then go in and knock their socks off!

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!

I have lost count of the number of times my project testing phase has been squeezed. When you are up against a deadline, your carefully planned 3-rounds of testing with time for bug fixes and validation suddenly slide out the door.

And yet, no one wants to put out a product that hasn’t been robustly tested. That’s just asking for trouble from the customer. I know iterative methods allow for rounds of improvements, but they should be functional, incremental improvements, not fixing bugs you let slip through because the testing wasn’t good, or long, enough. That’s my view, anyway.

It is tricky to schedule time for testing, because you don’t know what you’ll find. Perhaps the solution is so brilliantly coded that nothing buggy will be found. (Ha!) I think this is where some of the pressure comes from: sometimes managers disconnected from the process of creating something new feel that as each component of the software works fine, together the whole will work just perfectly. “If the build has been good enough, there won’t be much to fix.” If only.

Testing goes beyond simply making sure the code is good enough. We test the processes, integration, training materials, communication approach and more. Here are 5 quick tips that I’ve picked up over the years for testing. Perhaps they will be helpful to you too.

1. Keep notes

I know, keeping a note of exactly what you pressed and what happened is boring. Users don’t always understand the rationale of following the script and noting down what happened. Detailed notes help other people replicate the error so they can see it, understand it and fix it.

Get into the habit of documenting everything. You’ll be grateful later.

2. Try to break it

This is the part of testing I enjoy the most! And it kind of contradicts with following the script – except you should have test scripts for trying to break the product too.

Encourage testers to do things in the wrong order, use the product incorrectly and see what happens. You need to make sure it is adequately developed to deal with those use cases ‘in the wild’ as well as for the users who have read the instruction manual!

3. Test with real users

Talking of users reading the instruction manual, ideally testing should be done with the involvement of users. I have been on projects where testing has been done by a professional test team, in our test lab. That was great. The level of detail and accuracy and information provided was awesome and elevated our confidence in the product. Testers are brilliant.

But you should also involve some end users. They may find the test process regimented and a bit difficult to get on with, but a little training should help with that. That community will provide a different insight into how the product works and can give you feedback on usability and process that a testing professional might not know, not being an expert in their job function with the wider business context around that.

4. Test what you can’t see

A lot of testing in my experience has been around what buttons do on the screen, functionality, do you get the data you expect. But when working with professional testers (as opposed to subject matter experts and team members we’ve drafted in to help check the software meets their requirements) they have always focused on what you can’t see as well.

Those are the non-functional requirements. Does it meet the company security guidelines? Is it fast? Can we back it up and do those back ups work? You should have non-functional requirements in the product spec or as use cases, so make sure the testing doesn’t overlook those.

5. Plan the testing

Finally, and I know it sounds obvious, but all of those things above should be in a test plan. Sometimes the test team has written this on my projects, sometimes I’ve had to write it (and probably didn’t do that great a job). But whatever you do, to whatever level of quality, the important thing is that a test plan exists so you have some idea of what is expected, who is going to do it, what you are looking for and how the test results will be fed back to the people who can make the improvements.

Make sure a test plan is included in your overall project plan, and if you aren’t sure how to put one together, get some support from people who have done it before.

I’m not a tester, so I’m sure there is more to it than what I’ve written above from the point of view of a project manager. What would you add? Leave a comment below to tell me!