The Money Files

In the Northern hemisphere, we’re going into hibernation mode. The weather might be getting colder but the deadlines are hotting up as we approach year end. It’s always the same: leadership teams trying to get projects done before the end of the year, often for no real reason other than it’s an arbitrary date and it lets everyone start fresh in January.

However, if your financial year finishes in December, there could be good reason for trying to get everything done.

At this time of year there are also other distractions: people taking time off for holidays and the festivities. Here are 6 practical strategies that you can start using on your project to finish the year strong.

1. Plan for the holiday exodus

Map out who’s away and adjust your project timelines early. One of the problems I have found on projects is that I am not always told who will be on holiday because the individuals working on the project do not directly report to me. Check in with their line managers or ask each individual directly about their plans to be away over the holiday season.

2. Freeze your scope

Literally. Stop adding features or deliverables! When you get change requests, put them on the back burner until the new year. That will protect the capacity in the team in order to complete the work that you already have in your work stack.

3. Front-load work

Get critical tasks done before festive chaos hits. Even if you are not expecting chaos, you could still be caught off guard by key stakeholders being out of the office or decisions taking longer because decision makers are not around.

Try to get decisions documented and agreed as early as possible so that your team is not held up.

4. Automate handovers

Prep notes, shared docs, and checklists. If you have anything to hand over this season, make sure you're doing the prep work for it now. That also means making sure your project filing and archiving is up to date. Saved down any attachments from emails tidy up your SharePoint channels and make sure everyone is using the document storage the way that it should be used.

5. Celebrate early wins

Bring in treats or plan some virtual thank-yous for the team. This year my project team is celebrating in November because December is too busy and it's hard to get people to have the opportunity to meet up. If that feels like it will be the same for your team, consider moving any festive celebrations earlier in the year or pushing them to January. January often has the benefit of being cheaper as well!

6. Plan your restart

Schedule a January reset meeting before everyone disappears. Whether that is a lessons learned from a project before you will forget what happened, project scoping or a quarter one planning session, book the time now before all those recurring meetings start dropping into calendars. While you are at it, set up your steering meetings, any other governance meetings, regular project team meetings and anything else that needs to be in the diary on a recurring basis so that your team project sessions have protected time as you go into the new year.

What else do you do at this time of year that helps you keep everything on track to end the year in a good place?
 

I was contacted recently by a reader who wanted to know how to best prepare for starting work on a merger project. It wasn’t something she had done before, and while she wasn’t 100% responsible for the work, she wanted to feel a bit more confident going into some of the early discussions, especially around how she could shape the project management work to support the integration efforts.

Here are 5 things I thought she would benefit from starting with.

1. Due diligence

The first stage – at least in this case as the deal wasn’t yet done – should include due diligence. It’s important to know what you are letting yourself in for. As project managers, we don’t necessarily get involved in that. In my experience, it’s an exercise led by the Legal team with input from subject matter experts as required. But it should definitely be on the project plan.

2. Stage gates

I manage a lot of projects quite informally, but a merger wouldn’t be one of them. If you are in this situation, see if your PMO has a template for stage gates and work out what the project lifecycle would look like. Think about what criteria are going to be required to move out of one phase and into another. I would define those criteria so everyone is clear about what they look like and there is general understanding about when the project gets to move on.

3. What to merge

What, exactly, gets merged in a merge? There might be brand assets to redo, websites to redirect, but also teams to merge and processes. There might be IT systems or physical equipment.

What about legal contracts that need updating, or intellectual property? There is a lot to consider, so some project management effort should be put into identifying what actually needs to happen and when it should happen. It’s likely that the integration efforts will take some time, so it’s going to be a staged approach. When you know what needs to happen, you can help business leaders organise that into workstreams or phases that best represent the work.

4. Outputs

What does the world look like when the merger has happened? There might be a new vision, different approaches to staffing, new processes. Similar to identifying what needs to change, think about how you will know when you’ve got there. What are the success criteria? How will it feel? How will it work?

That’s a good exercise to identify what the outputs are likely to be, and therefore what work needs to go into making sure those outputs are delivered.

5. Ways of working

Finally, as with all projects, it’s worth thinking about how the project will run. How do you want it to run, and how can you influence how it is run?

Think about stakeholder engagement, what communications are required, how progress and performance will be tracked, what governance is required, what project controls look like… all the normal things. With so many moving parts on a project like this, it’s even more important to make sure everyone knows what is required of them and how they can contribute.

This type of project can be very complex, with a lot of risk attached, especially to do with losing key staff and market reputation. If the project feels big, it might be worth getting in some specialist help from project leaders or consultants who have done similar work before.

What else would you suggest for someone managing a merger or acquisition project? Let me know in the comments!

Let’s say you have been through your programme and are ready to close it out. There is obviously quite a lot to do, and the finance elements will be part of that. Here’s what to consider when closing out the financial management of a programme, inspired by the Standard for Programme Management.

Benefits stewardship

The programme will have created benefits, some of which have probably been realised as the work progressed. Towards the end of the programme, you may need to estimate the ongoing costs for making sure those benefits continue to be realised. For example, maybe recruiting an additional person to manage some deliverables once the programme team is stood down. This should last for as long as the benefits are going to be tracked for, or as long as you think is appropriate.

Any ongoing costs that will be passed to the operational teams should be made clear and budgeted in their ongoing profit and loss accounts for the department.

Leftover funding

Will you have any money left at the end of your programme? Probably not – in my experience project and programme teams tend to spend everything allocated to them!

On the off-chance that you do have funds left – let’s say, in the case of closing the programme a little earlier than expected – you should be in a position to hand some funding back. Any contingency funds that have not been used can be returned to the corporate ‘pot’.

Reporting

You’ve been creating financial reports for the duration of the programme, and those will now stop as the programme is wound up. However, stakeholders may be relying on that information. If there is the expectation that some of the financial reporting is still required, perhaps in a slightly different or amended format, you should put in place options to make that happen.

For example, perhaps another department can pick up running the reports, or they can be automated.

Tip: Even if you are automating the reports, please make sure each report has an owner! When we migrated a load of reports from a legacy system into a new one we weren’t sure which reports were used and which were no longer required because there was no data ownership. We didn’t migrate a bunch of them, figuring that if they were missed someone would say! Nobody said anything, so it’s probably those were simply no longer required, even though the system produced them regularly.

Sustainment

Sustainment of a programme is the work required to make sure the outcomes are maintained going forward, once the programme structure itself is no longer there to support them. Beyond benefits, there might be some additional funding required to sustain the programme’s vision, achievements or outcomes. For example, perhaps you implemented new tools and now the business needs to have someone in post to maintain that software.

In my experience, people who enjoy the environment of delivery are not always the same people who enjoy the day job. You may find that programme resources are not interested in staying on in ‘day job’ roles to support the ongoing running of whatever needs to be sustained, so you could end up having to budget for hiring new roles.

Close out checklist

At the end of your programme, check to make sure you have the following aspects covered from a budget perspective:

• Financial inputs to the programme closure report and any final financial reports or closure statements
• Updates to the financial management plan if necessary
• Updates to the lessons learned database or organisational knowledge repository
• Any related documents that might be useful in the future
• All invoices and supplier contracts wrapped up and closed
• Programme budget and cost centre/cost codes shut down so no further work can be allocated to them.

What else would you consider when closing out a programme budget? Let me 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!

Do you have a formal Change Control Board (CCB)? If not, this is the perfect time of year to be thinking about levelling up your processes and putting new ways of working in place to formalise the way change management is done across projects, programmes and the portfolio.

A Change Control Board is simply a group of experts that represent different organisational departments and who oversee both the process of change management and the different changes being put forward.

At a project level, your CCB is a group of people who know the project well and who can assess project-related changes, but at some point if your project is making changes to the live environment, like most IT and business change projects do, the change will need to be submitted to the wider, department or organisational CCB.

The role of the CCB is to:

• Assess the change
• Approve the change – in my experience, if the project team and project sponsor has already approved the change, there are few reasons why the CCB would then block a change
• Schedule the change
• Keep records about changes.

How it works

In our CCB, the functional lead or the project manager had to present the change. We had to talk about what it was, why it was useful and what it solved, and then make the case for whether it was a priority fix or not. If the change was considered a priority, it could go in the same day (mostly). If it wasn’t, it could be packaged up with a bunch of other small changes and go in the next release.

That made it easier to communicate changes to the end users.

Discussing the change

First, the change should be analyzed and discussed to see whether it has impacts beyond what the project team can comment on. The Change Control Board is convened to do that. I think the CCB is a really useful group and we relied on it in my last job. Our CCB looked at operational and project changes so the team could see the impact of ‘normal’ changes as well as the project-related ones.

I think it’s important that the CCB is made up of a cross-organisation group. It’s too common for changes (especially IT changes) to go in and for there not be a full understanding of the business impact somewhere else down the line. Complex ERP systems like SAP make that more likely, so a group of functional consultants getting together to discuss changes before they happen is a good thing.

I’ve had some changes rejected by the CCB because they didn’t have enough information to make an informed decision, or because something else was going on and they needed to wait on that, or because there was a change freeze. There might be many reasons why your change doesn’t go through.

Scheduling changes

The CCB can also schedule changes. There are normally scheduled windows to put changes in, especially in the live IT environment. That helps the support teams and the users know what is going to be different and what to look out for when they next log in.

Scheduling as a team also ensures that conflicting changes don’t get put in on top of each other. For example, if my project is updating the list of available categories in one part of the system, and another team is also updating that part of the system but taking away the category feature (that’s a bit extreme, but you see what I mean) then those conflicting changes can be discussed and overseen in an appropriate way.

It might involve putting them live in a particular order, or prioritising the changes so that one piece goes in this time and the additional change is put in next time.

I remember being told a story of a change in a data centre where engineers were working on cabling and flooring on both sides of a server stack. Without the support of flooring on both sides, the server stack toppled over! That’s the importance of making sure that changes are managed in a scheduled and sensible way.

We also had an emergency change procedure for anything that could not wait until the next release. On the SAP projects, for example, mostly things could be scheduled in a batch and changes pushed through on a fortnightly basis. But sometimes it was important to fix an issue straightaway without waiting until the next release. For example:

• Bug fixes
• Issues that affected customers
• Changes that went in and then didn’t work as expected.

All of these are emergency fixes to live systems that wouldn’t be appropriate to delay, and they are all issue-related, not nice-to-have features.

How does your CCB work?