The Money Files

While so many of us still use the humble spreadsheet for project management and tracking, there are lots of cool technologies out there that will (eventually) be game-changing for project managers. And I’m not talking about AI, although of course that is huge in our industry at the moment.

Project management tools are often seen as task-based, schedule-based, scenario-based products, but will that change when we bring more elements of gaming into the way that teams and results are managed?

Gamification

Gamified project management systems could incentivise teams to make progress. We could introduce a bit of healthy competition. I know not all teams are going to love the idea of gamified work, but in some teams it could provide a bit of engagement and interest. If your project management software has the option to award stars (for example) for contribution, then take a look at what features you could switch on.

I’m part of a community where likes on posts are rewarded – not for the person doing the liking but for the person being liked. The aim is to encourage thoughtful, helpful comments that the community finds valuable. I think it’s a balance between spending all your time crafting the perfect, likeable comment and doing your work, but I do think we’ll see more gamification coming into project management, and I’ve talked about that at conferences before.

Role-playing

I know, I cringe too when role-playing gets mentioned. However, when I’ve been on training courses and we’ve done some role-playing (for example, having a difficult conversation with a colleague) it has been very helpful in addressing the situation in real life.

If you think about it, you’ve probably used role-playing already in your projects. If you have ever demonstrated a solution to a group of customers, you’ve probably had someone playing the role of a customer placing an order or interacting with your product. Just do more of that! It really helps bring the product to life.

You could also look to incorporate role-playing scenarios in training and change management activities. Work with stakeholders and users to give them first-hand experience of the change in a safe environment, helping them see it from different roles in the journey, for example, what it will be like to interact with the product as a customer.

Virtual reality

Personally, I can’t say I’ve used VR for project delivery (yet) but it is a feature of science-based learning at my children’s school. They use VR headsets for educational purposes to explore science topics. Which is cool.

We could see the same for project deliverables, perhaps a virtual simulation of a building that users could walk around to see what it’s like before the construction is complete, or something like that. Perhaps it will get used for virtual project kick off meetings or simulation-based training. This community has probably seen examples of that in use. If you have, can you drop me a comment below and let us all know how that worked out for you?

How do you feel project management is going to adopt new tech (that may or may not be aligned to AI)? If you’ve seen any of it in practice I’d love to hear how you are using it! Thanks!

Quarter 3 of a calendar year is July, August and September. Your business year might not follow the same quarters, but wherever you are in your business year, it’s probably the right time to be looking ahead at what needs to come next. Here are 3 focus areas for Quarter 3.

Forward planning

Begin strategising and planning for high-priority projects in the upcoming quarters. That might look like warming up stakeholders, seeing who is going to be available to work on upcoming projects, doing some light discovery work or pre-initiation investigation, especially on the areas that are likely to take the most time such as procurement and contract negotiations, or getting suppliers to submit security information and forms, or the RFP process. (Not that I’m speaking from experience or anything!)

Involving the team in these discussions can help maintain their focus on future goals and the bigger picture, while hopefully getting you a head start when you come to get those projects going in earnest.

Process optimisation

There’s never a right time to optimise processes, in my experience. The process is in use and it works, so often it feels better to sort out something that is broken, or that is strategically important. But those inefficient processes contribute to low staff morale and wasting time, month after month, so it’s worth scheduling some time to put some effort in. Each quarter, tackle one point or a couple of points, and soon you’ll build up a momentum and improvements.

So how do we do this? Analyse the project management processes and methodologies. Look for inefficiencies or bottlenecks in workflows that could be streamlined for better performance in busier times. I would look through the lessons learned from recent projects and see what’s highlighted there that could be improved.

Ideally, you’d do a full analysis of all possible problems and highlight one or two from the priority list, but in reality that’s a load of work before you see any improvements. A better option might be to just trust your team. If they are telling you that the change control process is a pain in the behind, just focus in on that for now. Improve what is causing people the most headaches, and trust me, they’ll have an opinion on what that is if you ask them.

Tool use

Do a quick review of who is still using the project management software tools you have. People move on so it might be time to claw back licences from users who are no longer in the business or who have changed roles. And other people might benefit from having the licences.

On the topic of forward planning for the quarter, look at what projects are coming up and whether your current licence package is adequate. You might need to add in more licences if you’ve got more projects or more stakeholders needing access to the tools.

If you foresee a need to add in more users, it might be worth scheduling the training for them now so they can hit the ground running when they get their own account.

What else would you be doing at this time to feel prepared for the upcoming months ahead? Let me know in the comments!

Earlier this month I looked at a spring cleaning plan for sprucing up your portfolio and giving the live projects a bit of a health check. This doesn’t have to take long, but if spring is in the air where you are, it’s the perfect time to reassure yourself and stakeholders that everything is in order.

Last time we reviewed the portfolio in a general sense to check for alignment and relevance. Today, we’re talking about resource optimisation and reallocation, which is Step 2 (step 3 is setting priorities and a future plan – we’ll talk about that next time).

In this step, I’d encourage you to explore strategies for optimising resource allocation to ensure that key projects have the necessary support, while eliminating waste and inefficiencies. And that doesn’t mean we’re spring cleaning the workforce – this isn’t about layoffs or making roles redundant.

Review underutilised resources

Check in with your resource managers or team leaders and find out if there are any colleagues who are underutilised. This shows up in two ways:

1. they might not be working at full capacity as they haven’t been assigned enough work
2. they might be working on tasks that are not a suitable level for their expertise.

In my experience, we don’t often find people who have free time or are on the bench without good reason. Work expands to fill the time, so you might not find anyone sitting around waiting for work to be assigned to them. Make sure people are working on the right tasks and not filling up their time with smaller, less priority projects or team process improvements and things that aren’t helping the portfolio move closer to the strategic goals.

Then, check in with managers about their team members who have been assigned work that really isn’t a good use of their skills. I’m thinking of people who are doing tasks that are below their skill level, often because there aren’t any junior people available. If that looks like it is the case for your teams, see whether there are options to move work around so people with the right skill level are working on appropriate things. This can really help team morale as well as skill up some valuable resources for the future.

Check your tools

Next, check your resource management tools. Is that spreadsheet still doing it for you? Is it time to invest the effort into setting up resource profiles in the tools you already have?

Software can help with resource management, planning, forecasting and decision making, so if you don’t have anything suitable, maybe now you’ve reached a level of maturity across the portfolio where you could put together a case for investment.

Look at upcoming resource needs

Finally, take a look at projects in the pipeline. We’ve cleaned up what’s gone before, but part of spring cleaning is also making space for the new.

Look at what work is coming up and whether resources are available and have the right skills to be able to tackle new opportunities that arise. That might mean spending some time identifying what skills need to be trained in to the current teams or recruited in, or making decisions about contractors joining the team if necessary.

With this step about resource management, what you’re trying to do is identify resources and make sure they are working on appropriate projects – shifting key resources to areas of higher priority or need as appropriate, while taking future needs into account.

Next time I’ll look at some ways that clear priorities can help with your portfolio spring cleaning. See you soon!

I’ve been managing a programme for a while now, and it’s quite different from managing projects, or the very large projects that we call programmes that are really not programmes!

Programmes need their own budget as well as the budget of the projects, and here are the things I think should be included in that.

1. Costs of running the programme

It seems silly to point it out explicitly, but there are costs incurred from running a programme with a programme management structure.

For example, my time as programme manager needs to be costed and included along with any support resource from the programme office. Even though we are not full-time, the programme wouldn’t run without us so our costs have to go somewhere.

Ideally, there would also be a programme-level risk budget for handling unforeseen issues.

You may also find that on your programme there are other costs associated with running the programme, such as office space, software licences for third parties to access your programme management software (which is likely to be the same project management software everyone else uses, so hopefully not too large of an overhead there).

2. Assurance costs

Are you planning on having internal (or external) audits and reviews as part of the programme? If so, those costs should be picked up by the programme budget.

Internal reviews, in my experience, don’t cost anything except time, but if you are bringing in consultants or external auditors, there is definitely a cost associated with that (as well as time). Certification or compliance programmes may have extra costs here too, for example, if you have to comply to certain standards, going through the accreditation process is both time-consuming and normally costs something. There’s also often an annual cost to main the accreditation so factor that in too if your programme is multi-year.

Plan all those costs into the programme budget at the frequency and estimate required.

3. Benefits realisation costs

Benefits might be realised at project level, but you’ll likely have some programme benefits to track as well. And the cost of delivering and tracking those should be included somewhere – in your programme budget.

For example, you may need to programme software to create new reports. You may need a new role, and someone hired to go into that role. Some benefits might include making staff redundant due to organisational restructure, and there are costs associated with that activity too.

Plan all of those in at programme level. You may find that it’s useful to take the project-level benefits realisation costs into the programme budget as well so you can track benefits all in one place, but that’s up to you.

Project costs

Of course, there are costs to running the projects too, and in your overall programme budget, you’ll want visibility of those for forecasting and tracking. But these are the ‘obvious’ costs so it’s likely you already have them.

The project costs would normally include the large infrastructure type items that are necessary for the programme to move forward. The first project would normally take the hit for any large infrastructure-type investment, but that makes the business case for that project rather wobbly. You might decide that large capital costs are picked up by the programme as an overhead instead, and then each project goes forward on its own merit without having to fund the infrastructure required to make it and future projects work.

Talk to your financial analyst or project accountant for how best to apportion the costs across the programme and projects so it’s transparent and reasonable.

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!