Posts

My son is studying for his master’s degree in Geographic Information Systems Mapping (think Google Maps and some of the layers of data in there) and he has to write a paper on how he would approach a project to assess and implement a new GIS system. Given what I do for a living he asked me for some advice (first time for everything!). I took him through some project basics, and we got on to the subject of size. “Dad”, he asked me “Does size matter?”.

“Where do I start?” I thought. Yes, yes it does – and it could be the size of the company, the project complexity, the budget, the project team, the project relative to the size of the company, or the company relative to the size of a supplier. Or all those things. With so many variables I tried to split it in to 2 parts: (a) the project concepts that should stay the same regardless of size; (b) how to tailor the project to fit in with the size, culture, governance, and project experience of the company (or companies) that the project is for.

We started with what should stay the same. I told him that the approach you take to a project and the methodology should not change, whether using Prince2, the APM framework, or Agile development. But that the understanding of that approach and the degree to which you use it can vary from business to business. You still need to go through all the various stages such as supplier selection, planning, running the project, development, testing and dress rehearsals, implementation, and post implementation activity. And you must consider all the stages, as you skip them at your peril, but some may be more light touch depending on the size factors. I furnished him with some of my project management notes to review in his own time (yes, I have a small library of notes as even after 20 years in project management I still need to reference the odd thing every now and then).

We then talked about how size should be considered. In my career I’ve delivered projects for large and small financial firms and the experience can be very different. For example, in one firm I worked for the idea that you could just pop in and cross-check something with the CEO was quite refreshing. But depending on the size of client, as a project manager it means you have to be flexible and have to focus on different things to make sure that the project stays on track and is going to be delivered successfully. I drew my son a very basic matrix to highlight some of my observations relative to company size and asked him to relate this to the company he had in mind for his GIS assignment:

Size of Company Advantages Potential challenges
Large
  • Change framework is established and embedded
  • Varied and in-depth project experience
  • Potentially bigger budgets

 

  • Red tape / level of governance
  • Complex hierarchy
  • Finding the right people / all stakeholders
  • The number of stakeholders
  • High volume of competing projects (projects may be stopped, merged, or pointed in a different direction)
  • Can be complex and / or bespoke processes and procedures, especially if multi-national
Small
  • Can get to speak to the top easily
  • Can get things done quicker
  • Staff/teams more familiar with each other
  • Smaller portfolio of projects at any one time
  • Not enough resources in the business to spread the SME workload
  • Sometimes no Change Framework exists
  • Potentially less project exposure and experience
  • Potentially smaller budgets
  • Processes & procedures not always documented

He then said ‘ok, but what does this really mean in relation to the project?’ I told him it means several things. For example:

Planning – you need to carefully consider the planning process. Understanding how easy it is to get the project fully established and how long it will take to get decisions from those with the authority needs to be accommodated in the plan. You should be clear on the levels of governance required and the volumes and frequency of meetings and reporting as this could add complexity and time into your plan. Consideration should also be given to the lead times for bringing on board any in-house experts, for example checking if subject matter experts are readily available, or are the Business Architects tied up on other projects for the next 3 months. And in larger companies, resources don’t always continue to be available should the project timelines need to be extended, as they are booked to move on to other projects.

Stakeholders – it highlights the importance of identifying and engaging with stakeholders. Large organisations have many varied businesses and departments that could by impacted by the project or could be required to support the project, and you need to find all of these to ensure there are no surprises further down the line. Obtaining stakeholder engagement and buy-in can be a lengthy process but is essential for successful delivery of the project.

Governance – it can determine the governance approach and can Impact on how the project is to be managed. You need to ensure all the appropriate controls are in place, and that you understand all of the project artifacts that need to be delivered. Get the governance structure that suits the needs of the company.

Project team – the size and complexity of the project correlates to the number of people required, the roles to be covered, and how the team is structured. It will also affect the time required to manage people and obtain progress updates. And considering the size of the company, how big is the pool of available resources and what breadth of experience do they have.

Budget – how far does the budget stretch in relation to the required resources, taking into consideration in-house or external needs. You also need to consider if there is any contingency to cover additional expense or extended time, any impact on the scope (e.g. you can’t have everything you want) or does it limit Change Requests and anything targeted for a phase 2.

Supplier – it can influence the company’s bargaining power and how this relates back into budget or scope. You also need to consider if the supplier is going to be able to cope with the scale and demands of a large company in relation to the project.

‘Plenty of food for thought’ he said as he disappeared to start his research.

I’m keen to see how our discussion plays back into his assignment on the conclusion that size does matter.

Did you know that the average cost of a desk in central London is more than £8,000 p/a? Whilst it is slightly less expensive in other cities around the UK, that is a large overhead for any company – particularly if the space is not being used.

Almost 75% of City firms are reviewing their office space provision, focussing on how much space they really need. This follows the significant increase in remote working and flexible working during the pandemic. This is likely to be the new normal once the world recovers from these challenging times.

But have you ever wondered what is really involved in considering an office move? There may be more thank you think. From my experience there are four main stages: Strategy, Business Case, People Impact, and Planning. Let’s have a look at each of these in a little more detail.

Strategy

It seems obvious, but the strategy must consider if reducing your footprint is better achieved by relocation or by downsizing within existing space. And if a move or downsize is not viable, then you should consider how best to optimise the use of the existing space e.g. through subcontract or introducing franchises.

Depending on your size, you may also want to consider alternative arrangements that would satisfy your need, such as a central hub with spoke sites for drop in space established on the city periphery. A lot of the larger serviced office providers have multiple locations in a city, so it is possible to supplement a core location with multiple, flexible workspaces.

To help make these decisions, your initial thinking should be about where the office needs to be. Primarily this should fit with the overall business strategy and the client proposition. If you can, consider where the majority of your staff are located and how easily they can access the location.

Once that is clear, you should consider the alignment with Business Continuity plans, security requirements, and the levels of facility support expected (e.g. repairs, maintenance, cleaning).

officefloorplanNext, work out how you calculate the business needs and how much space is actually needed by considering desk space, offices, client meeting space, reception areas, break out areas, storage space, server rooms, and facilities (e.g. kitchen areas, locker rooms, showers, recreational space). This data may already be to hand, or you may need to start monitoring current utilisation. Fitting it all together and creating floor plans is the fun part.

Also consider your future headcount projections, taking account of peak periods. The shape and size of the teams, and how the resource or teams are split will be important. As will understanding which people need to be in the office, which teams need confidential space, which people can work remotely, and how you accommodate team working/meetings (bearing in mind being physically together can inspire innovation).

Finally, consider the terms of the existing lease and when it expires. This single factor may drive the strategy if you have a long lease that you cannot exit from early.

At this point you should understand what your options are, but not necessarily if any of these options are viable. For that you need to consider the numbers.

Business Case

I’m making a general assumption that if you are considering a property move then a budget will be able to be secured against other competing priorities.

You should already know the existing lease costs. You may also know the likely renewal costs and if these can be negotiated favourably (hopefully you are on good terms with the landlord!). For a move to new premises you should be able to obtain indictive costs for a new lease.

With regards to the move costs, you should include infrastructure costs for internal fit out/build, IT installation, new kit, the actual cost of moving, decommissioning, & lease exit costs. It will be more than you think.

Depending on whether you are relocating and where to, there may also be redundancy and recruitment costs (subject to HR policies and what is reasonable in changes to travel time).

Once all the costs have been collated, assess them against the perceived benefits derived from reduced future costs. There are likely to be different options, each with varying payback periods.

People Impact

From an individual’s perspective moving offices, or even moving space or floors within an office, can be an emotional event. Not everybody embraces change and some like things just as they are.

The staff experience is a key factor in any move:
cityscene

  • What does this mean for the staff in terms of commuting
  • Are they expected to use workspace management systems (desk sharing, flexible room booking)
  • Will there be parking facilities for bikes/cars
  • What is the surrounding area like (e.g. eateries, shopping, recreation, safety)
  • How will this impact morale. Not everybody wants to work flexibly, and some crave the social aspects of a workplace.

It’s important that you bring staff with you and keep them informed because you need them on your side and functioning positively. Finding champions within the business is always a good first step.

Planning

From a project management perspective, office moves can be a logistical challenge with multiple tasks that all need to be co-ordinated seamlessly, and quite frequently out of hours.

I won’t go into detail here, that’s for another time, but consider that you need to work with a number of suppliers and stakeholders to define the hour by hour schedule of events. And you need to anticipate problems and delays because they will happen, so build in plenty of contingency into the plan if the time allows.

At the end of the day, whatever you decide you need to make sure that every member of staff has everything they need and expect in the right place when they come in on Monday morning. Because no matter how successful everything else goes, that is what is important to them.

Given the option, who would have attempted a core banking system replacement entirely remotely? Definitely not me. I’ve always opted for everyone to be on-site in an effort to ensure issues are escalated quickly and resolved even quicker.

However, as we all know times have changed, we have been thrown into a world of remote working that looks likely to stay in one form or another for the foreseeable future. As a result, Projecting has recently had to manage a completely remote go-live implementation of a core banking system.

UAT & Dress rehearsal

During the final stages of UAT testing , the entire country went into full lockdown which was a bit of a shock.

The project team quickly moved to video conferencing sessions for daily catchups, with very few glitches. An unexpected benefit of this new world was that throughput of testing increased … was this because the project was coming close to signing off UAT and the pressure was on? Or was it fewer day to day business interruptions – phones, emails, or kitchen gossip? Although we will never know for sure it was a welcome side effect.

Once UAT was signed off, the final dress rehearsal and data migrations were all that remained, apart from the go-live process itself.

As the new banking system was hosted externally applying patches and new versions, or running data migrations, were always carried out remotely so that was less of a concern. However, under normal conditions both the system and data migration specialists would have been on-site for both the final dress rehearsal and the go-live.

Given that the implementation was going to be remote, a key part of the dress rehearsal was working out ‘plan B’ processes for absolutely everything, particularly in the event key staff had network issues or contracted Covid-19. Deputies were identified and processes documented to allow those deputies to step in. We would normally do this anyway, but we had to think about it differently this time.

Identified challenges for go-live

The final dress rehearsal (carried out remotely) was successful, but it did highlight several remote working challenges that we had to address prior to the go-live weekend:

Communication – which had mainly taken place over email and/or Instant messenger was not relevant for every situation, so we assessed the types of communication and identified the best medium for each type:

  • Quick updates to the team that required no response worked well over instant messenger
  • Progress updates were provided in a central area on Teams that everyone could see
  • The Issues Log was available on Teams
  • A video conference open session used to facilitate working groups to discuss issues etc.
  • Email was used for final formal signoff

Issue Raising – we had a problem with issues not being raised to the correct team members, which impacted prioritisation and resolution. We added an additional step to route all issues through the head of the relevant business area and they prioritised which issues needed resolved and which could wait. Although this weakness may have been highlighted in an on-site dress rehearsal, it may not have resulted in a change to the process as teams would have been sitting together and discussing the issues. Being remote, it is really important that the process is solid and stands up on its own. Any change to process between dress rehearsal and go-live had to be communicated effectively and the relevant team members trained.

Collaboration – central sharing of Information as opposed to emailing it. For the dress rehearsal, approvals took place over email and there was a lot of email traffic which was difficult to keep track of. For go-live, we moved to a model where all approval forms were stored on a Teams site, updated centrally, and visible to other areas so that everyone was kept informed without the additional email traffic. Only final signoff was done via email.

Data Changes – to capture any late changes to core data which might impact go-live, which we deemed a higher risk than normal with everyone working remotely, we carried out a final, technical data migration very close to the go-live to resolve any issues.

Once the go-live took place it was a long day but hugely successful with clear communication and effective, slick processes that utilised time and resource wisely.

Our top tips…

…for a successful remote implementation are:

  • A solid finish to UAT testing
  • A final dress rehearsal that mirrors a remote go-live
  • Amend processes for go-live after the dress rehearsal based on findings
  • Have deputies/plan Bs
  • Train the team on the go-live processes to ensure they follow them
  • A final technical data migration to highlight data issues
  • Select the right communication channels

If you have any questions on remote implementations or would like to chat through your project options, please do get in touch.

Once you have decided that a project needs to slow down, pause, or stop, there are various activities to carry out. Some activities apply in all cases, but some only apply to the specific decision that you have made. Let’s start with those that apply to everything:

  • Decision validation. All decision makers with any responsibility for the project need to be both consulted and, ideally, in agreement with the decision. It is always worth a double-check.
  • Next step clarity. As you start to communicate to both decision makers and the wider audience there will be questions and challenges about the decision. Prepare for these as much as possible in advance. Be clear on the rationale for the decision and the specific steps that you will take to slow down, pause, or stop the project. Understand any dependencies and expect to be asked what the impact on the organisation, individuals, external businesses, or suppliers will be.
  • Communication. Every organisation is different but a logical order is normally to tell the project team and the governance committees first (Steering Committee, Programme Board, etc.), followed by any impacted staff and business areas, followed by suppliers or external businesses that are dependent upon you. Communication should be quick so that, ideally, everyone who needs to know finds out on the same day. Don’t forget to communicate the reasons for the decision and next steps, as well as the decision itself.
  • Sensitivity. Individuals may feel a sense of disappointment or loss if a project is paused or stops, whether they are staff members, contractors, or suppliers. For some, this may also be a loss of role or a loss of income. Bear this in mind when communicating the news.

Then there are the activities that are dependent on the decision that you have taken.

Slowing Down

“Slowing down” in this context is where a project has to continue but needs to accommodate a reduction in funding and/or resources. If the project needs to slow down quickly it is unlikely that it will be possible to do a detailed analysis and full re-planning. The project manager and project team need to make some quick assessments focused on resource productivity, deadline criticality, scope, and quality.

Slowing down may not mean delaying deliverables. Ask first whether it is possible to achieve the same short-medium term outputs with fewer resources, allowing the project to continue with the same scope, deadlines, and quality. If that is not possible, the 3 levers in the project management armoury are:

  1. Deadlines – extend the project to smooth the workload
  2. Scope – reduce the scope to focus resource/funding on key areas
  3. Quality – don’t “gold-plate” deliverables when minimum viable product would be sufficient

Deadline extension is often the simplest solution. If deadlines cannot be extended, then decrease the scope; if the scope cannot be decreased, then focus on minimum viable product. If discrete scope items – or even discrete workstreams – are removed this helps reduces the need for detailed re-planning. However, any changes agreed will require a revision of the project documentation on resources, timelines, and scope. This must all be done with internal and external project dependencies in mind.

Pausing or Stopping a Project

A “paused” project will restart in the short to medium term; a “stopped” project will not restart. When you pause or stop a project carry out the following steps:

  • Record the decision formally with the appropriate governance bodies
  • Pay any final invoices, cancel purchase orders, etc.
  • Bring all documentation up to date, particularly the project plan, status reports, RAID logs, RACI matrix, and contact details of project team members (including external suppliers)
  • Collate all documents – including relevant emails, which can be specific to an individual – in a single, common location that is accessible to all relevant parties and ensure that the location is widely known
  • Perform a “lessons learned” analysis, if time allows, to feed in to your project or governance framework

Some of these actions may seem irrelevant for a project that is being stopped, but it is often the case that projects resurface in a different guise and it can be useful to have historic project information available.

In addition, for a paused project:

  • Create a “start up log” that identifies the initial actions that will need to be undertaken to get the project re-started
  • Diarise a fortnightly/monthly reminder to check project status in preparation for the restart

Our next article focuses on speedy restart and we will expand further on the “start up log” and contents.

Sometimes we find ourselves in a position where, for reasons outside of our control, there are not sufficient resources or finances to support a project or projects. This can be for a variety of reasons including cost restriction, resource availability, or changes in prioritisation. In this situation, decisions have to be made about the continuing viability of the project(s) in the short, medium, and long term. The decisions should take in to account the impact on the organisation as a whole, clients, staff, and external partners.

There are normally 4 options:

  • Continue with the project at the current speed if resources and/or funding can be found
  • Slow down the project by reducing resources and/or available funding
  • Pause the project completely for an agreed period before restarting it in future
  • Stop the project completely

To make these decisions quickly we use a 2-stage approach:

  1. Assess each project against a set of simple criteria and, where there are multiple projects, use a scoring mechanism to help with prioritisation (there is a list of criteria at the bottom of this article which, while not exhaustive, should be helpful)
  2. Once projects are prioritised, assess their ongoing viability and benefits against available resources and funding

As part of this consider whether it is possible to combine projects, share resources, reduce deliverables, or extend milestones. The end product should be a list of projects that are split into those that need to continue, those that can slow down or pause, and those that can stop. There may be grey areas so 2-3 iterations through the assessment is sometimes required. And do not be afraid to stop projects completely. Sometimes projects are only viable for a certain period and a previously strong business case may not survive a long delay. Difficult though the decision might be, particularly if significant investment has already been made (the “sunk cost fallacy”), sometimes stopping a project is the most beneficial thing that an organisation can do.

Working out which category your project should be in is the first step. Our next article will cover how to slow down, pause, or stop safely – with examples.

Assessment Criteria

  1. Is there a regulatory deadline or requirement that must be met?
  2. Is this project required to keep the business operating (e.g. replacement of a failing system, operational restructure)?
  3. Does this project provide any competitive advantage in the short, medium or long term?
  4. Does the project impact clients?
  5. Does the project impact staff or external partners?
  6. Is this project still viable if there is a delay or pause?
  7. Will the project cost be significantly increased if there is a delay or pause?
  8. Can there be a reduction or change in the scope of the project?
  9. Is there a risk of financial loss to the organisation?
  10. Is there the potential for reputational impact?

A year ago we published an article introducing DELTA AI, Projecting’s sister company focused on AI. Since then, the DELTA team have been busy talking to potential clients about AI. In Projecting Group we like to use initial client meetings to understand their needs (as we discussed in a recent DELTA AI article). However, clients often want us to lead with relevant use cases, as a good way to spark the conversation. There are many interesting use cases in the market, but most consultancies don’t go beyond the well-known offerings of the big well-funded players. One of DELTA AI’s strengths is that we have taken the time to investigate and understand the offerings of lesser known / earlier stage companies. This is where much of the innovation is taking place, as 89% of the AI ecosystem in the U.K. consists of startups with 50 or fewer employees (according to this Forbes article).

We see 3 main ways AI can help companies:

What is AI?

(See also this video from an event earlier in the year. It is in Spanish, but if you turn on the automatic English subtitles you will see a good example of the power of AI).

Over the last year, we’ve met many Projecting current or potential clients keen to talk about AI. This is already resulting in projects with an AI component.

A good example of this is the work we are doing with a company in the Wealth industry. The client asked Projecting to help them transform their Operating Model. In the first phase, working with a DELTA AI expert, we identified 3 main ways to apply AI to obtain quick wins. For the first opportunity, we are currently reviewing off-the-shelf tools. For the other two opportunities, we are developing business cases for building customised bots.

The DELTA AI team continue to focus on expanding knowledge and expertise in AI. We hold regular sessions across the teams to ensure the Projecting team are aware of the latest use cases identified. So, if you are interested in AI, feel free to contact anyone in the DELTA AI or Projecting teams. We’re always happy to have a chat.

We recently posted a link to a news article about the rate of IT project failures. There have been some very high profile, and some less high profile, IT project failures and outages in the past couple of years.

IT projects and programmes, large and small, are often both complex and complicated. Particularly when they involve the migration of data from existing systems to new systems. If you have worked on this type of project, then we aren’t telling you anything new.

We thought it might be useful to talk about why these projects can be difficult and how you might increase the likelihood of success.

The Challenges

The level of difficulty in these projects is driven by the:

  • Number of existing systems, the connectivity between systems, and external interfaces;
  • Functionality of the new system(s), any customisation, and the regulatory requirements;
  • Amount of data to be migrated, the structure of the data (clients, accounts, funds, stocks, etc.), and the data quality;
  • Number of system users, internal subject matter expertise, and internal project experience.

And that is only part of the delivery challenge. There will usually be an overlay of cost constraints, time constraints, and, sometimes, political constraints. It may be a multi-national project, it may span different divisions or businesses, and it can be across time zones. All of which increase the time, cost, and complexity.

Changes to any one of the things in the list above can, and will, affect everything else.

So, what can you do about it?

The core aspects of project management – governance, plans, risk logs, dependency tracking, etc. – are all important for a successful project but we would like to be more specific than that. These are our top tips based on experience:

  • Look before you leap. Everyone wants to get in to the action, but you must not skip detailed planning. We know it is laborious, uses lots of resources, and it can feel as if you are getting nowhere, but if you look at every component in detail you are much less likely to come a cropper later.
  • Mobilise properly. If you start the project with the wrong mix of skills and experience, it is difficult to recover, and you will lose both time and momentum. In your planning, make sure you understand who you need and when.
  • Map it out. Whether it is the system components, interfaces, or data migration, map it out. The more you understand about how everything is connected, the easier it will be to manage the project, keep it joined up, and assess the impact of any changes.
  • Never stop testing. It can be the easiest corner to cut, often backed by the implicit assumptions that “everything will be fine” or “we can fix it afterwards”. As recent press coverage shows, these assumptions are not necessarily correct. Test the functionality, interfaces, migrated data, systems access, volume, overnight processes, and everything else. You need to be confident.
  • Reconcile everything. It is one of the hardest things to do but it is critical. Reconcile your existing systems before your start, reconcile at every stage of the project, reconcile when you are testing migration, reconcile when you go live, reconcile across new systems and interfaces. Reconcile clients and accounts, reconcile financial amounts, reconcile static data. You need to know that everything is right.
  • Make good decisions. At each stage of the project making good decisions is key. Everyone will have worked hard to determine scope, timescales, and budgets. There may be good reason to change something but don’t do it without considering the evidence and expertise available to you. Quick decisions, sometimes forced by political pressure, almost always cause future problems.

This is a wide-ranging and multi-faceted subject to cover in a very short article. Every one of these projects have complexities and nuances that you could never conceive of at the outset but will be expected to manage when they arise, against a backdrop of time, cost and political pressure.

There is no magic solution but if you focus on detailing and mapping everything up front, making sure you test and reconcile everything as thoroughly as you can, and making open and honest decisions as you go through, you will increase your chances of success.

You can probably tell that we enjoy this stuff. If we can help, or you just want to pick our brains, feel free to get in touch.