, , ,

Can AI replace project managers? We asked ChatGPT.

Most of you by now, if you weren’t already aware of it, will have noticed in the media the buzz around ChatGPT, an AI chatbot launched in November 2022 by OpenAI. With a small amount of existential trepidation we went straight to the question that matters (to us!) most: “Can AI replace project managers?”.

While the writing style is a little formulaic, it provided an interesting breakdown of where AI could and could not currently assist in the delivery of projects, highlighting the key skills that project managers bring:

“Can AI replace project Managers?” – response generated by ChatGPT

Artificial Intelligence (AI) has the potential to revolutionize many industries, including project management. However, it is unlikely that AI can completely replace project managers in the near future. While AI can assist project managers in certain tasks such as scheduling, resource allocation, and risk management, project management involves a lot of human interaction, decision making, and problem solving, which are still difficult for AI to replicate. Additionally, project managers also play important roles in communication, motivation, and leadership, which are not easily replicated by AI.

One of the main responsibilities of project managers is scheduling, which involves creating a plan for the project, setting deadlines, and ensuring that all tasks are completed on time. AI can assist in scheduling tasks by analyzing data, identifying patterns, and making predictions about project timelines. However, AI systems lack the ability to consider all the nuances and variables that a human project manager can take into account while creating a schedule.

Another important responsibility of project managers is resource allocation, which involves determining which resources (e.g. personnel, equipment, etc.) are needed for the project, and ensuring that they are available when needed. AI can assist project managers in resource allocation by analyzing data and identifying patterns that can help predict resource usage. However, AI systems lack the ability to make judgement calls and take into account the human aspect of resource allocation, such as personal abilities and preferences.

Risk management is another important responsibility of project managers. They need to identify potential risks that could impact the project and take steps to mitigate or avoid them. AI can assist project managers in risk management by analyzing data, identifying patterns, and making predictions about potential risks. However, AI systems lack the ability to anticipate and mitigate risks that are not based on past data.

Project management involves a lot of human interaction, decision making, and problem solving, which are still difficult for AI to replicate. Project managers need to be able to communicate effectively with team members, stakeholders, and clients, adapt their communication style to different audiences and be able to explain complex technical concepts in simple terms. AI is not yet advanced enough to replicate this level of communication.

Motivation is another important aspect of project management. Project managers need to be able to motivate team members to work towards a common goal, and to overcome obstacles. They need to be able to create a positive and productive work environment. AI is not yet advanced enough to replicate this level of motivation.

Leadership is also an important aspect of project management. Project managers need to be able to lead teams and make important decisions. They need to be able to set a vision for the project and inspire others to work towards it. AI is not yet advanced enough to replicate this level of leadership.

In summary, while AI can assist project managers in certain tasks, it is unlikely to completely replace them in the near future. Project management involves a lot of human interaction, decision making and problem solving, which are still difficult for AI to replicate. Additionally, project managers also play important roles in communication, motivation, and leadership, which are not easily replicated by AI.

/por
, ,

ESG Projects

If you search the internet for ESG (Environment, Social, and Governance) and responsible and sustainable investing, you’ll find there is a vast amount of information about it. And with so much information it can be quite difficult to distil. When it comes to putting a project together around a broad-ranging and fast-moving subject such as this, it can be tricky.

From a project management perspective, let’s look at some of the challenges you may encounter at the early stages of the project:

  • New and enhanced regulation is constantly emerging – in addition to the existing ESG regulation that has come into force, there is regulation that will become effective this year or next year, and some regulation still in the white paper stage. Understanding what is relevant and what you need to address now can be a minefield and will need your compliance team to work closely with the investment team to agree what is relevant for your business now (and needs addressing now) and what will need to be accounted for in the future
  • Service providers are developing new ESG-related data modules – this is making available a plethora of factors, scores, indices, and benchmarks that you can use for internal and external ESG reporting. But determining which, if any, are most appropriate to the business needs is a complex matter and needs some dedicated focus with plenty of lead time
  • Software developments bringing new and enhanced packages – new and existing system suppliers are introducing additional software functions and capability to monitor, model, and report ESG data. Similar to the point above, it is difficult to know exactly what is needed both internally and externally so perhaps don’t go for nirvana at the outset, rather start with the basics and build on that over time
  • IT Architects need to ensure the solutions are sustainable – the proposed business strategy and processes for ESG must not be built on rocky foundations, i.e. the underlying systems will need to support future developments. You should consider the end-to-end process, and build any necessary time and budget into the plan to accommodate, for example, new data linkages and system enhancements
  • Quantity and quality of data – there are many competing data providers in the market which can make selection difficult, particularly when you consider the cost and in-house ability to understand the data, understand how scores are determined, and ultimately what the data is telling you

What does this mean from a project perspective?

  • Difficulty in defining and finalising requirements
  • Difficulty in setting milestones
  • Hard to contain the scope of the project, output, and deliverables
  • There is a need for dedicated senior engagement & decision making
  • The initiatives will suck up business stakeholder resource and project resources

How do you overcome some of the uncertainty?

My overriding approach would be to say ‘be brave’. By that I mean not to aim for all singing, all dancing solutions at the outset, but that you draw a line under what you know and have today and work from that. In due course, once you have formalised the approach and embedded the minimum standards, then you can start looking at future enhancements.

If you consider ESG from a programme perspective, it makes it easier to break initiatives down into manageable chunks. Develop individual workstreams and run things in sequence as far as possible. Don’t try and do everything at once; have a delivery roadmap. And don’t be surprised if you have 5 or 6 significant projects or workstreams within the programme.

Here are a few questions to consider with the project team to help structure the programme of works:

  • What is it that the business needs to do as an absolute minimum to cover its activities e.g. from a TCFD or SFDS perspective?
  • What are the strategic targets the business aims to achieve e.g. PRI membership or Stewardship Code membership? If the business is going down this route, then a gap analysis is a good place to start
  • What are the internal policies, are they all written down and clearly defined e.g. for Voting and Engagements?
  • Do you have any areas where you have limited existing material or current policies are not as extensive as they are required to be? A lot of material may naturally focus on an equity perspective, however, it is important to demonstrate, as much as is practical, that you take ESG into account for all asset classes
  • What are the internal processes & practices, and are they all written down, clearly defined, and understood? Is everybody following them?
  • Do you understand and monitor your third-party service providers ESG practices? If not, what steps do you need to take to ensure you are provided with the relevant information and reports?
  • Are you able to demonstrate, through case studies and examples, how ESG principles have been put into practice?
  • Have you got all the necessary evidence for the reporting periods required? Is this presentable? Or do you need to build new monitoring and reporting capability (for both internal and external consumption)?
  • What is the business doing internally at an entity level, e.g. what actions are staff personally taking such as reducing their carbon footprints or using sustainable energy suppliers?

If you consider the challenges and have answers to these types of questions, that should allow you to start formulating a Terms of Reference from which the high-level plan can be defined.

One final message – There will undoubtedly be amendments as the project works through the finer detail (which should be through formal Change Control) and you should account for that in your planning.

/por
,

Whose Project is it anyway?

Actually, it’s yours. Yes, there might be a project or programme manager – and other project colleagues like business analysts or project officers – but once you are on the project team there is a collective responsibility to deliver. Whether you are a sponsor, a business stakeholder, or a team member assigned to represent your business area, you will have responsibilities as part of the project team.

However, it might not always be clear what those responsibilities are, and it is the job of the project or programme manager – and more experienced team members – to help and guide you, particularly if this is your first time on a project. Projects are a team effort and everyone has an important part to play.

Whether you join the project from the beginning or part of the way through, there will be some things that you need to know (and if you don’t get told, ask):

  • What is the purpose of the project; what problems will it solve, what are the key outputs, and what does success look like?
  • What is the project lifecycle; what are the project stages and/or phases and what are the timeframes? Are you involved all of the way through?
  • How will the project be managed on a day-to-day and week-to-week basis, e.g. project meetings, steering committees, etc.? What will your time commitment be?
  • What will you be responsible and accountable for; what activities do you need to undertake and what are your deadlines?

The activities you need to undertake might be wide-ranging – reading regulations, documenting business processes, specifying requirements or management information, providing subject matter expertise, and testing systems are all good examples. It is important that you are clear on everything that you will be involved in.

Every member of a project team should know what is expected of them, even if it takes a few weeks to make sure that the initial roles, responsibilities, and activities are all agreed upon and understood. They will also evolve as the project progresses, so the communication and clarification should never stop.

But my current role is already full-time!

Sometimes individuals are seconded to project teams on a full-time basis if the project is large enough, but more commonly project activities will be alongside your current role. That can be challenging because you will have responsibilities to your current role and to the project, both with activities that need to be done and with deadlines that need to be met. Managing both is one of the main challenges when you are working on a project.

Structure, planning, and management support (both project and line) maximise the chances of success. Once you understand the project meetings or workshops you need to attend and the activities you need to undertake, make your best estimate of how much time you need to allocate to the project. You are assessing whether you have sufficient time to meet your project responsibilities alongside the responsibilities of your day job.

If you do not believe that you sensibly can do both, then you need to discuss this as soon as possible with both your line manager and the project manager. Or maybe you feel that you don’t have the right skills and experience to fulfil the project role. Human nature and business pressure might mean that this is a difficult subject to raise, but you do not want to put either your day job or the project at risk. Perhaps the project manager can redistribute some project responsibilities to make it more manageable, or perhaps some of your day-to-day responsibilities can be backfilled. You won’t know until you ask or escalate your concerns.

For any project, you need the right project team members with the necessary skills, experience, and capacity. It is the responsibility of everyone on the project team to make sure that happens – and to be open and honest about where they can (and can’t) contribute to that.

/por
, ,

Turning Projects Around

We often get asked what to do if a project is stalling or failing. There is no single right answer, but there are some steps that we suggest.

We find it useful to declare a project ‘amnesty’ at the outset. All project team members and stakeholders – internal and external – need to be open and honest about every aspect of the project. This is difficult to achieve if they are concerned about negative consequences or criticism of their project performance or actions. This is not necessarily easy, particularly if there have been significant failings, but the more you can keep the focus on moving forward, the quicker you can remediate the issues.

The next step is to investigate why the project is stalling or failing. If you don’t understand what the problem is, you can’t fix it (except by luck). There are lots of different reasons why a project might run into difficulties. It might be common project problems like scope creep, resource challenges, or technical delays, or it could be factors outside of the project manager’s control such as budget cuts or strategic changes.

Once you understand the problem(s), critically assess the ongoing viability and validity of the project. Companies and sectors change; a project that made sense 18 months ago might not make sense now. We’ve written before that one of the most difficult things to do is to stop a project, particularly where you have invested time and money. Sometimes projects stall or fail because the project team and stakeholders realise that the project has no longevity before a formal decision is made to stop it.

Confirming that the project is still viable and understanding what needs to be fixed are vital steps before beginning the turnaround process, as you might decide that stopping the project is the best option.

Approaching the turnaround process

The turnaround process itself can take different forms and it depends on how much ‘turnaround’ is required. Sometimes, simply re-baselining, adding resource, or reducing the scope are sufficient to re-energise the project. Other times, you may need to take more substantial measures such as changing a supplier or installing a new project team. This short article is not going to attempt to list specific solutions – there are literally books written on this – but what is important is that you use the problem assessment that you made at the beginning to objectively identify the key issues and develop the resolutions.

Also, be conscious that any turnaround work normally takes place under significant time pressure. At the point that you begin, the project is probably already delayed, the expectation will be that it continues, and any further delay needs to be minimised. It is important to balance – and manage – the expectations of getting the project back up and running quickly (if it is still a viable project) and taking the right amount of time to both assess the problems and implement the solutions.

Last, but by no means least, is the project governance. If your project has reached a point of failure then the governance, for whatever reason, has not been as effective as it needed to be. The project governance should be investigated – and revised if necessary – as part of the turnaround process. The shape of the new governance should prevent the same issues from arising again.

Project turnaround can be complicated, business and time-critical, and can carry a significant human and financial impact. Good governance and early action minimise the risk of a project getting to this stage but does not completely remove that risk.

/por
,

Are Project Management skills transferable?

A few weeks ago, I wrote about whether the size of the organisation matters when undertaking a project. My son asked me this when considering implementing a GIS mapping system as part of his Master’s degree. The other thought-provoking question he asked me was ‘could I do the implementation’? Roughly translated, I took this to mean ‘can a project manager work on any project?’

My instinct was to say “yes”, but like any good project manager, I wanted to consider the evidence for such a statement.

What is the role of a project manager?

The job of a project manager includes these four broad areas:

  1. Assuming responsibility for the delivery of the whole project
  2. Employing the relevant project management knowledge, tools, techniques & processes to meet the project requirements and deliverables
  3. Engaging and managing stakeholders
  4. Leading and guiding the team, noting that project teams often include people who don’t usually work together, people from different organisations and across multiple geographies, and sometimes with different systems, cultures and aspirations

Whilst specific responsibilities may vary depending on industry and project type, a project manager is broadly defined as someone who leads the project, working closely with all stakeholders, doing everything from ensuring clarity around the scope of work, educating individuals, project coordination, planning, and managing the timelines, scope, budgets and deliverables associated with the project.

What are the skills required of a project manager?

It’s very common to think about things like project planning, governance, organisation, and reporting. But the project manager is also a communicator and leader, motivating the team, making decisions, resolving conflicts, and solving problems.

Essentially anything you can think of that a manager or leader should do, then the project manager should have to do that too.

So, are project management skills transferable?

Yes, I would say project management skills are transferable, but the value add comes in the experience of the sector and types of projects.

I’ve worked in financial services for my whole career so I can turn my hand to managing projects related to Investments, Lending, Banking, Cards and Mortgages. But what about other industries? Well I know I could project manage the build of a piece of furniture (🗎 by David Hamilton), and I could most likely project manage the renovation of a house (although I probably wouldn’t be as effective as others more experienced in that area), but I feel I would struggle to project manage the complete development of a new office block.

Whilst the principles of project management are applicable for all of these, it is the value of understanding the subject matter that makes a difference. Certain skills can be applied regardless, for example around governance, planning & scheduling, resourcing, budget management, benefit management, and communication. But there are other elements where you really need to be a Subject Matter Expert (SME) such as Requirements gathering, and the identification & understanding of the severity of Risks, Issues and Dependencies.

And then there are some skills that sit in the middle such as Business case completion, understanding Regulations, Testing, Training, and Tracking & Monitoring. You can manage these but unless you understand the subject matter, you’ll probably be a bit slower & less efficient.

There are other aspects that impact too. Every client is different, so every approach is different. This makes every project very different from the last and the project manager needs to be able to adapt.

Does a project manager have to understand all aspects of the project?

To be a successful project manager you should have the right tools and know-how to choose which tool to use for which project. Being a good project manager doesn’t mean knowing all the answers off the top of your head. It’s how you find and provide the answers that makes you valuable as a project manager.

The project manager doesn’t have to understand every task to the extreme degree. For example, if a development task is assigned to a specific programmer, you don’t have to understand the code the programmer uses or how they write that code. If you have a team of strong Business Analysts then you can rely on them for the detailed knowledge, and you can rely on the business SME’s to give the business view. However, a word of caution on relying too much on the business. If the PM has worked in the area before and knows the business, then they are much better prepared to ask the questions that need to be asked. On the other side of the coin, if all you know is the task basics and how it affects or relates to other tasks in the project, that could be enough.

My conclusion was that the skills are transferable. But in considering who is going to be the project manager you will want to weigh up the balance between project complexity and risk of the project against the experience and knowledge of the project manager in that specific line of business. Or considering this another way, how much the project manager needs to hit the ground running and how far you would be prepared to potentially sacrifice on time, cost and quality of the project delivery.

/por
, ,

The Influence of Scale on Projects

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.

/por
, , ,

Nuevos retos de la digitalización bancaria

Hay un concepto del que ahora se habla continuamente: el de la “digitalización”. Las entidades financieras están inmersas en una dura carrera, en realidad una auténtica maratón, para adaptarse a las exigencias que la digitalización implica.

Una de las últimas propuestas relativas a esta idea tiene que ver con la creación del “euro digital”, una forma de dinero que emitiría el Banco Central en un formato estrictamente digital, sin soporte físico (https://www.ecb.europa.eu/pub/pdf/other/Report_on_a_digital_euro~4d7268b458.en.pdf). Su impacto podría ser semejante al que tuvo en su momento la introducción de la moneda por los griegos, una innovación que dio origen a un nuevo sistema con un conjunto de características y reglas propias diseñadas para hacer que la población confiara en él y lo utilizara en su vida diaria.

Hay algunas preguntas que rápidamente vienen a la cabeza para poder entender y definir el alcance del cambio:

  • ¿Cómo se verán afectadas las entidades financieras?
  • ¿Podrán los clientes minoristas acceder directamente a estas monedas? Si éste fuera el caso, ¿perderán los bancos la función de intermediarios financieros?
  • ¿Cuál será la infraestructura y el diseño funcional de la nueva forma de dinero?

Se estima que se tomará la decisión acerca de si se emite este tipo de moneda hacia mediados de 2021. A partir de ese momento surgirá el proyecto de implementación que podría durar un mínimo de 2 años.

La experiencia en otros grandes programas de adaptación a una realidad cambiante, como la transición de las referencias LIBOR en el que Projecting ha colaborado tanto en UK como España, permite anticipar un esquema de líneas de trabajo (“workstreams”) que habrán de incluirse en la estructura del proyecto de implantación:

  1. Legal: El euro digital plantearía diversas cuestiones legales, involucraría nuevos documentos y políticas legales, así como revisar los existentes.
  2. Negocio: Qué áreas están afectadas. Este punto ayudará a identificar los actores (“stakeholders”) clave que estarán involucrados en el proyecto.
  3. Contabilidad: ¿Supone algún cambio a la hora de contabilizar?
  4. Operacional: Desafíos importantes pueden surgir alrededor de la nueva infraestructura requerida. Hay que identificar qué sistemas y procesos están afectados, qué nuevos desarrollos y tecnologías serán necesarias. Ambas formas de dinero (las existentes hoy en día, así como el nuevo euro digital) convivirían, implicando que los procesos y sistemas para ambas tendrían que coexistir y confluir.
  5. Cumplimiento y blanqueo de capitales: Los pagos usando euro digital deberán respetar las normas de lucha contra el blanqueo de capitales y evasión fiscal.
  6. Comunicación: Qué mensajes hay que enviar a los clientes fuera de la organización (a través de la página web, carta, telefónica, …)
  7. Riesgo cibernético: Desafíos técnicos conllevan riesgos cibernéticos. Revisar la gestión de los mismos formaría parte del proyecto.

Los actores del sistema financiero deben estar preparados para este cambio y prever en la medida de lo posible sus impactos, así como planificar en que consistiría el gran proyecto de integración, implementación y adaptación a esta nueva forma de dinero.

/por
,

Assembling Furniture like a Project Manager

Like many people, the lockdowns have afforded me the opportunity to do a fair amount of DIY. Nothing major, but lots of little tasks that I’ve been meaning to get around to for ages. One of those was ordering and assembling a sideboard. I was talking to my wife about it when she pointed out that I was treating it like a project. She was right. And I approach almost everything as if it was a project (doesn’t everyone?). So, here I am writing about assembling furniture like a project manager.

Things were initiated with an idea. We had inherited some tea sets and ornaments last year and we had nowhere to put them. We didn’t want to keep them in boxes so we did a review of our current storage and discussed some options on how we could increase it. The obvious choice was another sideboard in the living room.

Then came the requirements. Easy bits first – dimensions and size constraints in the room and estimating the size of sideboard needed with a bit to spare (always have contingency!). Then the trickier bits like number of doors, drawers, and colour scheme, followed by ‘nice to have’ things like having legs tall enough that it was easy to hoover under.

A bit of stakeholder engagement on my part turned that ‘nice to have’ into a ‘must-have’ (even though I do all of the hoovering, just saying). It turned out that having tall legs was a constraint that made it quite tricky to meet the other requirements. After looking at literally thousands of options online over a period of weeks, we eventually found one that ticked all of the boxes (and we then double-checked our criteria just to make sure we hadn’t changed our minds on anything).

Then I read the reviews. “Good sideboard but almost impossible to assemble”; “Hired 2 different handymen and neither of them could do it”; “High quality but took days to put together”. Great.

We reconsidered our options. We had a plan B, but we actually really liked Plan A and we were quite invested in it now. With the optimism of the project manager, I was convinced I could do the assembly so we ordered it. After all, preparation is the key to success so hopefully two months of planning and researching would result in a 1-day project.

“Project Go-Live”

Screws

When the big day came, I was ready! I knew the risks and I had a plan. Any mistakes might mean I had to take it apart and start again, but I started on Saturday morning so that I could continue on Sunday if I needed too. I laid out every single piece (c300 + panel pins) and checked them against the instructions to make sure I had everything. Then I checked them again. I read through the instructions once (24 pages) and then I read them through again, while at the same time laying out all of the pieces on the floor in the order that I thought I would need to put them together.

As soon as I started I realised why the assembly was difficult; it was the dependencies. There were lots of near-identical pieces with very minor differences, e.g. a groove or a hole in a slightly different place, and the instructions weren’t always clear on which one to use. So I double-checked every instruction and I tried to visualise how the next pieces would fit together. I also tried very hard not to let my attention wander, although that was easier said than done. As most people who have been on a call with me know, I have two young, noisy, and energetic dogs who are always keen to help (in this instance by either barking at the partially assembled sideboard or chewing screwdrivers).

Six and a half hours later, via a couple of mistakes that I had to correct, I had a completed sideboard and a happy key stakeholder. One of the doors wasn’t hanging exactly right (I still need to fix that) but I was out of steam for the day. I tidied away all of my tools, put the packaging in the recycling, and sat down to relax.

If you’ve made it to the end of this article – and congratulations if you have – then you may be thinking that you spotted a lot of project management terms in there (initiation, planning, risks, dependencies, constraints, options, stakeholders, contingency) and you would be quite right. There are even a few allusions, some psychology, and a post go-live issue. And that is exactly how I thought about it and described it as I was doing it.

Because I assemble furniture like a project manager.

 

/por
,

Communication for Project Managers

Communication is a key skill for any PM (Project Manager not Prime Minister) – although these tips can apply to all types of roles.  Project communication is difficult to get right. Why? Because it needs to be coherent and understood by everyone on the project team or even wider depending on the audience.  Let’s have a look at the groups and types of stakeholder that a PM interacts with:

  • Project team – consists of a mix of experienced and less experienced team members
  • Business users – teams associated with the project but not necessarily on the team
  • Stakeholders – business area managers up to executives and board levels
  • Executive – Executives in other business areas
  • Other project teams – teams working on different projects which may be impacted
  • Technical staff – SMEs or technology teams who need to be engaged
  • Suppliers – who may be impacted by your project or be part of it
  • Customers – In some projects, the end user may be customers external to your organisation

Then factor in all the types of communication, e.g. status reports, weekly updates, meeting progress, issues, steering committees, wider updates, product launches, marketing etc..  You can see why it is an area that quickly gets out of hand resulting in communication that is not fit for purpose.

The importance of communication

Communication is so important to get right for so many reasons, e.g. project effectiveness, buy-in from your own team and others, keeping up morale, keeping executive engagement and belief in the project, informing everyone when things are progressing well and more importantly when they are not to keep confidence in the project.

People absorb information differently and their own experiences influence how a communication is interpreted by an individual.  It’s widely accepted that people must hear a message several times, in different ways before it is understood, or interpreted as it was intended.

Following the 7 C’s of communication below, which you may have seen referenced but seldom adhered to, is a start

  • Completeness – be complete in the message, not half the story
  • Conciseness – fewer words are better
  • Consideration – consider all people who the communication needs to reach
  • Correctness – be factual and have the facts correct
  • Courtesy – be polite in getting the message across
  • Clarity – to achieve clarity of understanding
  • Concreteness – ensure the logic of the message fits together

It is quite a challenge to get it right but if you review your communications in line with the above points, it will improve your chances of having all of the bases covered.

Communication tactics

Other good tactics in your armoury should be a:

Communication strategy – one that has been circulated and approved – agreeing up front how communication should work and devising strategies to getting the most out of it is a valuable exercise.

Communication sub-committee – Pick some difficult people (sorry rephrase… some people who are not afraid to challenge or make their views heard) and run any communication past them to get valuable insight to how others receive the message.  Using people from different areas or levels of seniority works to get an overall balanced view.

Channels – There are so many types of channels available to use that selecting the most appropriate can make a real difference to effectiveness of the message. Don’t always communicate everything via email! Can you use instant messaging, video conferencing, produce a short video, or use an internal social media channel? And think about the type of message you are delivering – good news, bad news, instruction, update – in the context of how you deliver it.

Feedback loop – Finally, review and amend your communication based on feedback, see it as an iterative process.  Communication should evolve over the course of a project and, even if it is not quite right to begin with, it will get there. Communication needs to be appropriate for the culture, knowing your audience takes time and it is very likely to be different from company to company.  Always be available to answer questions post any communication.

Not all items types of communication are needed or indeed required on every project.  The key is using your communication toolbox, i.e. picking the correct channel for a particular type of message or group.  The goal is to communicate in an engaging way, keeping it quick and easy for people to keep up to speed without too much burden.

During the past year we have seen a lot of development in communications – necessitated by home working and lack of face to face engagement – from day to day project comms to managing go-live implementations remotely. Please do get in touch if you want to talk about the approaches that we are using.

/por
, ,

Is it time for an office move?

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.

/por
, ,

Remote Go-live implementations

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.

/por
,

APM Blog – RAG Status

David Hamilton recently had two instalments of a blog on the use of RAG status in projects published by the Association for Project Management. We’d be grateful for your comments over at the APM site.

https://www.apm.org.uk/blog/rag-status-a-tool-not-a-weapon/

https://www.apm.org.uk/blog/rag-status-using-the-tool-the-best-way/

/por
, ,

Cómo ralentizar, interrumpir o detener proyectos de forma segura

Una vez se ha tomado la decisión de que un proyecto debe ralentizarse, pausarse o detenerse, hay varias actividades a llevar a cabo. Algunas actividades aplican en todos los casos, pero otras solo aplican en función de la decisión específica que se haya tomado. Comencemos con las que aplican a todo:

  • Validación de decisiones. Todos los responsables de la toma de decisiones del proyecto deben ser consultados e, idealmente, estar de acuerdo con la decisión. Siempre vale la pena verificarlo dos veces.
  • Claridad en próximos pasos. A medida que comience a comunicarse tanto con los que han tomado las decisiones como con el público en general, habrá preguntas y desafíos sobre la decisión. Hay que prepararse, de antemano, tanto como sea posible. Hay que ser claro sobre la justificación de la decisión y los pasos específicos que se tomarán para desacelerar, pausar o detener el proyecto. Es clave comprender las dependencias y anticipar preguntas sobre el impacto en la organización, las personas, las empresas externas o los proveedores.
  • Comunicación. Cada organización es diferente, pero un orden lógico es comunicárselo primero al equipo del proyecto y a los comités ejecutivos (Comité Directivo, Junta de Programa, etc.), seguido por el personal afectado y las áreas comerciales, seguidos por proveedores o empresas externas que tengan alguna dependencia del proyecto. La comunicación debe ser rápida para que, idealmente, todos los que necesitan saberlo se enteren el mismo día. Es importante comunicar también los motivos de la decisión y los próximos pasos, no solo la decisión en sí.
  • Sensibilidad. Las personas pueden sentir una sensación de decepción o pérdida si un proyecto se interrumpe o se detiene, ya sean miembros del personal, contratistas o proveedores. Para algunos, esto también puede ser una pérdida de función o una pérdida de ingresos. Hay que tener esto en cuenta al comunicar las noticias.

 

Luego están las actividades que dependen de la decisión que haya tomado.

Ralentizar

En este contexto, nos referimos a donde un proyecto va a continuar, pero necesita acomodarse a una reducción de fondos y/o recursos. Si el proyecto necesita ralentizarse rápidamente, es poco probable que sea posible hacer un análisis detallado y una planificación completa. El gerente y el equipo de proyecto deben realizar algunas evaluaciones rápidas centradas en la productividad de los recursos, la importancia de los plazos, el alcance y la calidad. Disminuir la velocidad puede no significar retrasar los entregables. Si es posible lograr los mismos resultados a corto y medio plazo con menos recursos, esto permitirá que el proyecto continúe con el mismo alcance, plazos y calidad. En la mayoría de los casos, eso no es posible, por lo que las 3 palancas de gestión de proyectos son:

 

  1. Plazos: ampliar el proyecto para suavizar la carga de trabajo
  2. Alcance: reducir el alcance para centrar los recursos/ fondos en áreas clave
  3. Calidad: no entregar “entregables de oro” cuando un producto viable mínimo puede ser suficiente

 

La extensión de la fecha límite suele ser la solución más simple. Si los plazos no pueden extenderse, entonces se puede disminuir el alcance; si no se puede disminuir el alcance, se puede enfocar en un producto mínimo viable. Si se eliminan elementos de alcance especificos, o incluso flujos de trabajo discretos, esto ayudará a reducir la necesidad de una planificación detallada. Sin embargo, cualquier cambio acordado requerirá una revisión de la documentación del proyecto sobre recursos, plazos y alcance. Todo esto debe hacerse teniendo en cuenta las dependencias internas y externas del proyecto.

Interrumpir o detener un proyecto

Un proyecto “en pausa” se reiniciará en el corto a medio plazo; un proyecto “detenido” no se reiniciará. Cuando interrumpamos o detengamos un proyecto, hay que realizar los siguientes pasos:

  • Acordar la decisión formalmente con los órganos de gobierno apropiados
  • Pagar las facturas finales, cancelar las órdenes de compra, etc.
  • Actualizar toda la documentación, en particular el plan del proyecto, los informes de estado, los registros RAID, la matriz RACI y los datos de contacto de los miembros del equipo del proyecto (incluidos los proveedores externos)
  • Compartir todos los documentos, incluidos los correos electrónicos relevantes, que pueden ser específicos para un individuo, en una única ubicación común que sea accesible para todas las partes relevantes y asegurarse de que la ubicación sea conocida por todos
  • Realizar un análisis de “lecciones aprendidas”, si el tiempo lo permite, para alimentar al proyecto o marco de gobierno

 

Algunas de estas acciones pueden parecer irrelevantes para un proyecto que se está deteniendo, pero a menudo sucede que los proyectos resurgen de una forma diferente y puede ser útil tener información histórica del proyecto disponible.

Además, para un proyecto en pausa es conveniente:

  • Crear un “registro de inicio” que identifique las acciones iniciales que deberán realizarse para reiniciar el proyecto.
  • Programar un recordatorio quincenal / mensual para verificar el estado del proyecto en preparación para el reinicio

Nuestro próximo artículo se centra en el reinicio rápido y ampliaremos más sobre el “registro de inicio” y los contenidos.

/por

Priorizar proyectos en circunstancias difíciles

Algunas veces nos encontramos en una posición donde, por razones fuera de nuestro control, no hay suficientes recursos o finanzas para apoyar un proyecto o proyectos. Esto puede deberse a una variedad de razones que incluyen reducción de costes, disponibilidad de recursos o cambios al priorizar. En esta situación, se deben tomar decisiones sobre la viabilidad continua de los proyectos a corto, medio y largo plazo. Las decisiones deben tener en cuenta el impacto en la organización en general, los clientes, el personal y los socios externos.

Normalmente hay 4 opciones:

  • Continuar con el proyecto a la velocidad actual si se pueden encontrar recursos y/o fondos
  • Disminuir la velocidad del proyecto al reducir los recursos y/o financiación disponible
  • Pausar el proyecto por completo durante un período acordado antes de reiniciarlo en el futuro
  • Detener el proyecto por completo

Para tomar estas decisiones rápidamente utilizamos un enfoque de 2 etapas:

  1. Evaluar cada proyecto en función de un conjunto de criterios simples y, cuando haya varios proyectos, usar un mecanismo de puntuación para ayudar a priorizar (hay una lista de criterios al final de este artículo que, aunque no exhaustiva, debería ser útil)
  2. Una vez que se priorizan los proyectos, evaluar su viabilidad y continuos beneficios contra los recursos y fondos disponibles

Como parte de esto, hay que considerar si es posible combinar proyectos, compartir recursos, reducir entregas o extender hitos. El producto final debe ser una lista de proyectos que se dividen en aquellos que necesitan continuar, aquellos que pueden disminuir o pausar, y aquellos que pueden detenerse. Puede haber áreas grises, por lo que a veces se requieren 2-3 iteraciones a través de la evaluación. No hay que tener miedo a detener los proyectos por completo. A veces, los proyectos solo son viables durante un cierto período y un caso de negocio previamente sólido puede no sobrevivir a un retraso largo. Aunque la decisión sea difícil, particularmente si ya se ha realizado una inversión significativa (la “falacia de los costes hundidos”), a veces detener un proyecto es lo más beneficioso que puede hacer una organización.

Determinar en qué categoría debe estar su proyecto es el primer paso. Nuestro próximo artículo tratará cómo reducir la velocidad, pausar o detenerse de manera segura, con ejemplos.

Criterios de evaluación:

  1. ¿Hay un plazo reglamentario o un requisito que deba cumplirse?
  2. ¿Se requiere este proyecto para mantener el negocio en funcionamiento (por ejemplo, reemplazo de un sistema defectuoso, reestructuración operativa)?
  3. ¿Este proyecto ofrece alguna ventaja competitiva a corto, medio o largo plazo?
  4. ¿El proyecto impacta a los clientes?
  5. ¿El proyecto impacta al personal o socios externos?
  6. ¿Sigue siendo viable este proyecto si hay una demora o pausa?
  7. ¿Se incrementará significativamente el coste del proyecto si hay una demora o pausa?
  8. ¿Puede haber una reducción o cambio en el alcance del proyecto?
  9. ¿Existe un riesgo de pérdida financiera para la organización?
  10. ¿Existe un potencial impacto reputacional?
/por
,

Project Management: Experience or Qualifications?

I am in the dawn of my career, therefore I have a couple of years of experience and a couple of qualifications under my belt. You could say I’m equally (un)qualified in both. So what have I learnt so far? Principally, no project will ever run as smoothly as your qualifications would lead you to believe.

This doesn’t weaken the value of the qualifications I’ve achieved. For me, they serve as a reminder of the solution I should be aiming for, even though running the perfect project is up there with the likelihood I’ll be struck by lightning or win the lottery. In reality, we don’t live in an ideal world and even a perfect framework cannot plan for every possibility. It would be a waste of time to try.

My experiences so far have taught me things I would never have been able to learn from a book. In my opinion, these are the most important learning events that will make me a great Project Manager. Having said this, I cannot downplay what I did learn from books. My qualifications serve as my lifebelt when drowning in work. From my studies, I remember that even in the most unique situation, there is always a method to apply to the madness. It’s my second sense of logic when my brain is in over its head.

Often the range of experience on a team is what makes it great. It brings together skills and knowledge gained in different parts of the industry. This allows projects to benefit from the shared experience of the whole team. If experience is why we succeed, qualifications are how we succeed. They are the common ground which helps a team come together. I benefit from both my qualifications and my colleagues’ experience – in all being able to speak the same language, even when it doesn’t feel like it! In Projecting, we have a vast pool of knowledge and experience that I can call on.

A good project manager is not just made from how many acronyms they can remember to apply to a project, nor only from how many times they’ve been around the block, but I have learnt that one without the other is insufficient. Qualifications give me confidence that I am moving in the right direction; experience is the comfort in knowing I can overcome whatever obstacles that direction may bring, and that sweet spot right between the two is where the magic happens!

/por
,

Juggling Chainsaws

“Juggling is sometimes called the art of controlling patterns, controlling patterns in time and space.” – American mathematician Ronald Graham

Part of the fun of project management is trying to juggle a myriad of tasks and priorities that regularly change and sometimes conflict. Some people think of this as “spinning plates” but we think it is more like “juggling chainsaws”.

If you watch someone spinning plates, a popular pastime on 1980s Sunday night TV, you’ll notice several things. The “spinner” doesn’t increase the number of plates until the plates already spinning are under control, once all of the plates are spinning it is relatively easy to keep them turning, and the plates are independent so if one falls it doesn’t affect the others,.

We find that juggling chainsaws is a better analogy for project management. Everything is interdependent, there is no respite, and dropping a single chainsaw can cause irreparable damage. You can even give your chainsaws names – like “budget” and “deliverables” and “resources”. If you drop anyone of them then you could be in trouble.

Project management is also like juggling because you wouldn’t normally start off with the biggest, most complex thing you can find. It’s important to understand the principles, build your experience, and stretch yourself. It is also important to work out what types of project suit you and your personality. Not everyone wants to run global, 20-workstream, 500-person projects. Some project managers want to be in roles where they can get their hands-dirty with doing rather than managing. That is okay.

Dealing with “drops”

Assuming that you have mastered the art, at whatever level you decide, then the most important thing is what to do when you drop something. And you will drop things. The normal reaction is to pick them straight back up but is that the right thing to do? If you don’t know why you dropped it, the likelihood is that you will drop it again if you pick it back up. Work out why you dropped it.

Once you’ve worked out why you dropped it then you can decide whether to pick it back up again. If you were just trying to manage too many things maybe it is time to rethink your project structure. If it was a lack of skills or experience, maybe your project team needs to change. There can be lots of reasons why things drop but don’t just assume you need to pick them back up again without thinking it through. Also, if they do need picked back up, don’t assume that it needs to be you who does it.

You should also learn to predict when something is about to drop. Those signs can come from project governance – e.g. actions incomplete, lots of amber and red milestones – or from your emotional intelligence – feeling out of control, under pressure, loss of confidence. It differs from person to person but learn to recognise the signs. Don’t be afraid to escalate, don’t be afraid to take corrective action, and don’t be afraid to ask for help.

Project management really can be like juggling chainsaws; it’s great to be in the audience but it is the juggler that really feels the pressure.

At Projecting, across our combined team we have been juggling chainsaws for centuries and we have a scratch or two to show for it.

/por
,

How Do You Make Your Projects Client-centric?

Client–centric is an approach to doing business that focuses on creating a positive experience for the client. Client–centric businesses ensure that the client is at the centre of a business’s philosophy, operations or ideas 

We were prompted to write this article as a result of two examples we heard about recently in financial services firms. 

In the first, a firm had developed a new service to meet the needs of its clients. Yet, it had not actually asked those clients what they needed. The firm had assumed that, since some of their competitors had this service, there must be a demand. Initial uptake of the new service suggested, at best, a very limited demand. 

In the second, a firm started a new project that was going to be fully “client-centric”. The project is well underway and, as far as we are told, no one has defined what client-centric means or spoken to any of their clients.  

Neither of these situations is uncommon and being client-centric means different things to different people on different projects. The two examples above are, of course, considering the needs of their clients. Often those needs are considered in the very early stages of project definition, when seeking approval for a business case for example. Maintaining the focus on client benefits can be very difficult when in the depths of project delivery.

Achieving client-centricity 

We believe that if you want to have that client-centricity, you must focus on the client from the beginning to the end, as opposed to during or after delivery. We believe that this is possible by following these 6 steps in your analysis phase and building your project around the findings:  

  1. Agree what client–centricity means for you. Does it mean breadth of services, is it tailored to specific client segments, is it sector-leading or fast-following, etc.  
  2. Identify your client interactions. Give these processes the focus and time to ensure they are slick and re-engineered if required, these should be your number one priority. 
  3. Ask your clients for feedback. This could be on services, processes, communication, or whatever is relevant to the project you are undertaking. You can prioritise the feedback received to ensure you are focusing on the right areas.  
  4. Act on your clients’ feedback. Incorporate it into your project where that is the right thing to do. Then track that it is delivered. If you are not acting on it, tell the clients why. 
  5. Think about the future. As well as acting on what your clients currently want, think about new developments in your sector, market trends, etc, to shape your future proposition.  
  6. Use the project to build the relationship. In recent years, projects have often been perceived as imposition on clients, e.g. GDPR, rather a benefit to them. Where a project is providing benefits, there is an opportunity to send a positive message not only to clients directly but to all client-facing team members.  

If client-centricity is a goal then it is a long–term goal, it is a cultural shift for the organisation, it requires everything to be seen through the lens of the client, and it takes time. 

However, with running a project there is an opportunity as change is imminent, therefore thinking of the client from the start of the process assists with the shift to client-centricity.   

As always, we are happy to chat about this so please feel free to get in touch.  

/por
, ,

How to kill a Zombie Project

Zombie – /ˈzɒmbi/ (noun):- (in popular fiction): a person or reanimated corpse that has been turned into a creature capable of movement but not of rational thought, which feeds on human flesh.

It’s not only people who can become zombies; it’s projects too. Have you ever encountered a project – or proposed project – that refuses to die? You’ve chopped off its limbs and buried it, but it still manages to resurrect itself. Even when you think it’s gone, it pops up at your next project board, maybe in a slightly different guise, taking up time and distracting from more important activities.

Maybe it is a project that has been around for years, feeding on money and resources, but never delivering anything. Or it might be a project idea that has struggled to get support but gets continually re-presented. We shall refer to these as “zombies”. It might be worth thinking about one of your own “zombies” as you read this.

It is very tempting to take a zombie on head-on, as you probably feel that you have logic and right on your side, but we respectfully suggest a more measured approach. Our starting point is that direct attempts to kill the zombie thus far, whether by you or others, have been unsuccessful (otherwise it wouldn’t still be around).

The first things to consider are:

  • Why does it exist? At one point, it may have been a great idea. Maybe it had benefits for a particular department, or it made sense when the business had a different structure or products. Perhaps it had a particularly vocal senior supporter.
  • Why won’t it die? It still has enough supporters – either because they believe in it or because they have already invested so much time and energy. Or it might actually just be a good project.

If you have come to that conclusion that the zombie must die, then there should be sensible reasons for that – it is not aligned to current strategy, it has been superseded by other projects or events, or it will never deliver enough benefit to be prioritised. Sometimes, there are just so many things happening that you need to clear away any distractions so you can see the wood for the trees.

Then comes the difficult bit; actually killing it once and for all. Have we ever managed to kill a zombie project? Yes, using both analysis and sensitivity. If you are telling someone, or a group, that their project will never be delivered, won’t generate the benefits they had hoped for, or is no longer relevant in the company/environment, then you are more likely to get their support if you can offer them an alternative, such as:

  • Including part of their requirements in a different project
  • Asking them to support other projects beneficial for their department or area of interest
  • Involving their team in other, relevant projects

While you are delivering an unwanted message to one person, it is often the case that they are representing a team, department or business area for which the project is a high priority (even if it is a low priority in the big scheme of things) and that is the message that they have to deliver. We believe that you can never lose sight of that impact.

Linked to this is timing. The opportunities for killing off zombie projects, or at least doing a critical review, are often after an agreed threshold has been reached, e.g. a project has been on the list for 2 years but never started; when you take on a new project, programme or department and have the opportunity to do a full review of everything, or; a large, company-wide project is about to take place, e.g. core system replacement, so all resources should be focused on that.

Last, but not least, what prevents resurrection? If it is an active project, it should be formally closed down; if it is a project proposal, it should be formally rejected by the appropriate committee. Keeping a log of closed/rejected projects with a detailed explanation of the rationale makes it easier to identify it if it resurfaces, particularly for a new project manager who might not know the history.

Killing a zombie is not easy so, if you can, stop them being created in the first place.

/por
,

Introducing DELTA AI

delta-ai.com

We attend a number of conferences and events and meet a lot of Fintech startups, working at the forefront of Artificial Intelligence, Blockchain and other technologies. This is fun and fulfilling at a personal development level but also helps us be able to think outside the box in our daily conversations with our clients. Often their challenges or objectives can be addressed relatively quickly and inexpensively using Artificial Intelligence solutions, such as Robotic Process Automation, predictive modelling based on Machine Learning or something as simple as a chatbot. This usually comes as a surprise to them as their experience of AI is as a hyperbole-filled topic oversold and under-delivered in the market to date. Most of our clients haven’t got the time to separate fact from fiction so we do a lot of educating in simple language about AI and what is and what isn’t achievable.

We are at an exceptional point in the market when it comes to the possibilities of AI. Most organisations haven’t even begun to scratch the surface and there are plenty of low-hanging fruits that can be quickly and easily captured. To illustrate this, here are a few very simple yet powerful use cases that we have discussed in recent months with clients:

  • Churn predictor: using Machine Learning over existing internal data to predict which customers are most likely to leave and focus your retention efforts more accurately. If you can reduce your churn levels and maintain your underlying customer acquisition, your growth automatically increases! This doesn’t need setting up a data lake or buying social media feeds, you can generally get good results with internal data
  • Onboarding process automation: using a Robotic Process Automation tool, you can (very quickly) automate the (usually very manual) process of running any customer checks, setting up details on different systems etc. Over time you can apply Machine Learning to this so that any exceptions are learnt from and your manual involvement keeps going down
  • Sales team augmentation: there are multiple tools already in the market that can be implemented to augment your sales team’s capabilities. From virtual PAs that allow your team to hand off scheduling and meeting booking to a machine, to intelligent insight preparation based on your internal CRM and external news feeds that can warn your sales team when they should be contacting a customer or what products they are likely to be interested in
  • Agent Help desk: if you rely on an external network of agents to bring you business and be the face of your brand, you need to make sure they understand your products, tools and processes. Often queries are very simple and easy to deal with but require a human to interact with the agent, introducing delay and increasing the likelihood of confusion. A simple chatbot interface can help address the majority of queries quickly and inexpensively allowing the human team to focus on the more complex questions

To address these types of challenges better, we have set up DELTA AI as part of the Projecting Group. At DELTA AI we are already working with various clients on implementing AI solutions. DELTA AI doesn’t build software but bridges the knowledge, cultural and language gaps between our clients and startups to deliver practical solutions, simply and inexpensively. In the coming months we will be posting a series of articles detailing what types of solutions are feasible in each part of the financial services sector. In the meantime, for more information please visit the DELTA AI website (delta-ai.com) or speak to any of the Projecting team.

/por
, ,

Navigating at Speed

navigation – navɪˈɡeɪʃ(ə)n/  (noun) – the process or activity of accurately ascertaining one’s position and planning and following a route.

One of the hardest parts – perhaps the hardest part – of project management is navigation. Continuous navigation. The project manager is constantly assessing the position and navigating the project through an ever-changing landscape of priorities, deliverables, corporate restructures, stakeholder divergence, and morale black-spots. Any respite is short-lived and quickly forgotten when the next storm hits. The route changes regularly as the landscape changes and, often, the planning process is only able to go a few steps ahead with any kind of accuracy.

The challenge for the project manager is to understand and track all of these moving parts, continually modify the route, keep stakeholders up to date, take everyone with them on the journey, and to do it both calmly and with pace. If you thought that the project manager simply writes a plan at the beginning and then tracks it, you would be wrong. If you recognise that project managers are constantly bombarded with new information and have to immediately assess and assimilate, you would be right. It should come as no surprise when, in a project with hundreds or thousands of moving parts, the project manager cannot immediately articulate every impact of the information they only found out 3 minutes ago.

While it is important to recognise the nature of the environments we operate in, it is more important to develop ways of operating successfully within them. A good project manager can navigate successfully given sufficient time to do it, but the luxury of time is rarely afforded. Navigating within the time available, and with the responsiveness expected, is what matters.

Intellectual flexibility is important – you need to juggle a lot of things in your head and be comfortable with constant change – but the ability, and bravery, to take intellectual shortcuts is more important. To stop you running aground use these 6 tips to steer towards calmer seas:

  1. Looking ahead. Work out how far ahead you can see. Sometimes you can see to the end of the project, sometimes only a few weeks or months ahead. Knowing how far you can see determines how you approach planning, team management, governance, and everything else.
  2. Recognising pitfalls. You cannot critically assess everything in the landscape so you need to prioritise. You are unlikely to trip over a blade of grass but a large boulder may fall on you. Work out what to spend your time on.
  3. Knowing your toolkit. Every project manager should have a toolkit of methodologies, processes, templates, techniques, etc. The more tools you have, the quicker you can select the right one, and the better you are at using them, the faster you can operate. Even the simplest job, like finding the right template, can waste an hour if you don’t have it to hand.
  4. Delegating. If you take everything on yourself then you will quickly be bogged down. Being an effective delegator can save you hours every week.
  5. Using experience. If you have done something before, or someone you trust has, use that knowledge. That can be anything from “here is a plan I prepared earlier” to “the last 3 times I have run identical projects, this activity has taken 40-45 days”. Don’t go back to first principles when you already have a reasonable estimate.
  6. Communicating. Navigating depends on information. The project manager must be constantly gathering and sharing information. And everyone on the project should be keeping the project manager up to date.

There is no silver bullet for successful project navigation. Sometimes you receive emails faster than you can read them, your phone doesn’t stop ringing, you spend 8 hours a day in meetings, and there is a seemingly endless merry-go-around of status reports. This is when navigation – and everything that it takes to do it well – is most important.

/por
, ,

I’ve Started So I’ll Finish

Have you ever been on a project or programme where there is a change of project or programme manager part-way through?

In an ideal world you would have the same project manager from start to finish, but the reality is that this doesn’t always happen. It might be that the PM becomes disenfranchised or demotivated, the project might change direction, the skills needed through the project lifecycle might differ, or the project manager may simply be the wrong fit.

Whatever your role on a project – from business sponsor to business analyst – this is something that you will have to deal with. It can be easy to feel let down if someone leaves but the project show must go on. When it does happen, you should not be surprised but you should be prepared. That is also true if you are the project or programme manager that is moving on.

We take a 4-step approach:

  1. Anticipate it. If the project or programme is particularly long (over 18 months), complex, there is a lot of travel, hours are long, and/or the pressure is high, experience says that the likelihood of a change in personnel is higher
  2. Plan for it. At the outset think about the skills and experience needed for the duration of the project or programme. For example:
    1. Beginning: ability to take disparate views, vague objectives, unclear resource requirements, and mould them in to a functioning project
    2. Middle: build and keep momentum, maintain morale, manage issues and changes, and keep driving the project forward
    3. End: ramp up the pressure, cope with deadline changes/replanning, unstick showstoppers, and get it over the line
  3. Discuss it. If you are thinking of leaving (or thinking that someone should leave!) discuss it. The issues may not be resolvable, e.g. by a change of role, but at least you can create an exit plan that works for all parties
  4. Seize it. Every change is an opportunity. It can create the opportunity to re-evaluation an entire project and it can be the trigger for implementing beneficial changes

Also consider the psychological aspect. The “classic change curve” describes the emotions that accompany change – from excitement and expectation at the beginning, through despair when the going gets tough, to acceptance and positivity towards the end. An awareness of which stage you are at will help in anticipating issues and managing them.

Last, but not least, what about the project or programme manager who is coming in half-way through? They are often expected to understand the project, personalities, politics, culture, and history in days when it really takes weeks (usually months). Everyone wants the project manager to get up to speed quickly so they can start delivering but they must be given the opportunity to do so. That means time, access to the right people, and as much knowledge transfer as you can muster. If you are using the opportunity to, for example, change the project structure then it makes it easier if this is complete before the new person starts (unless you want them to design and implement it).

None of the above means that we should go in to every project expecting the PM (particularly if you are the PM) not to make it to the end. Everyone wants to see it through. But change does happen, and you should be prepared.

In our next article, “Project Orienteering” we’ll be discussing how to navigate your way through projects when you don’t know where you are going, how to get there, and everything keeps changing.

/por
,

Hindsight – The Unkindest Cut of All

Hindsight

As project managers and business analysts, we have all looked back at our successes and failures and thought, why did we do that? It’s a common feature of governance to produce a formal “Lessons Learned” report for the Project Sponsor but:-

a) Does this go far enough?
b) Is it given the value it deserves?
c) Is it used by you in your project role?

These reports are only lessons if someone learns from them and should be aimed at a 360° audience; Project Sponsors, SMEs, Project Boards, PMs, BAs, Change teams. In project roles, it’s important that each assignment forms its own unique component on your CV and that this experience is carried forward to the next one. It doesn’t matter how long you have been working in projects, as Indiana Jones once said, “it’s not the age, it’s the mileage”.

How do we maximise the benefits of the lessons learned?

Personally, I have always kept a log of both specific and generic events worthy of recording. How do you know they are worthy? Bearing in mind that you will probably need to submit a report on closing a stage or project, note down as much as you can. Formal project methodology can direct you to which categories and to the format of that report but does that matter? You will (or should!) know by the time you come to produce this what is worthy or not, exactly how the sponsor wants it styled, and what can be useful in future.

What are these so-called lessons?

Lessons are experiences that we want to digest and be able to regurgitate when we need them. Not fast food that is gorged and discarded at the first opportunity. Sometimes they need to be introspective and you should not be frightened to do a critique on your own performance. It is almost impossible, if not actually impossible, to complete a project in which you were exemplary throughout; accept it and take it forward positively. Add to your knowledge portfolio.

How to use them?

So, after a few projects, you will have built up a collection of lessons that are unique to your experiences. You will be able to use them in other roles and projects. They will help you find roles as you can reference them at interviews, crucially. Employers and potential employers will hear that not only do you have a portfolio of solutions to pitfalls but that you are constantly learning and adding value. Learning your lessons may tip the balance in your favour.

Store this knowledge portfolio in a very safe place and make foresight the tastiest cut.

Here endeth the lesson on lessons.

/por
, ,

How to Create Sense on Projects

In Article 1, we put forward our view that project management is not common sense. We also said that creating a “common sense” on projects was important for project success.

Project Management is about getting everyone on the same page and going in the same direction. Trying to maintain that through organisational restructures, team changes, time constraints, budget challenges, and changing priorities is hard for every project manager and project team.

The first person that needs to be clear on the direction and end goal is you. Then you need to create that common SENSE:

S is for Simplicity. Keep your communication simple and short. If you can summarise it in 3 bullet points it is quicker to say and easier to share.

E is for Efficiency. Everyone needs time to listen and digest. Help create time by managing workloads, e.g. don’t ask for things at the last minute or asks for a slide deck “just in case”.

N is for Neutrality. Keep your head, keep perspective, and don’t get frustrated. Everyone is starting from a different place and needs support. Keeping calm, inwardly and outwardly, sets you apart.

S is for Straight-talking. You cannot achieve consensus without open discussion. Sometimes you need to be brave, you always need to be honest, and you should never be afraid to speak up.

E is for Engagement. There will be many, and sometimes conflicting, views. Respect the opinions of others, seek to understand, and use patience and diplomacy to create consensus.

It’s not easy and you will need to do it from before the project starts until after the project ends. But we believe that if you can get everyone going in the same direction it really does increase the likelihood of success.

In our next article, “I’ve started so I’ll finish” we’ll be discussing how initiating, running, and then getting a project over the line require different skills and not everyone has all of them.

/por
, ,

Is Project Management Common Sense?

Lots of people will tell you that project management is just common sense, including project managers. You can find articles, books and methodologies devoted to the idea that it is. And at the beginning of a recent seminar 80% of our audience, mainly project professionals, agreed with that.

We are not so sure.

If we take a standard definition of common sense – “the ability to perceive, understand and judge things that are common to nearly all people and can reasonably be expected of nearly all people without need for debate” – then we can apply that to our own project experiences.

While much of project management theory, for good reason, is about creating a commonality (a “common sense”) across the project, the reality is that this is incredibly difficult to do in a moving corporate environment with changing scope, timelines, priorities, and personnel. That lack of commonality can apply to both what the project is trying to achieve (the objectives or deliverables) and how it is trying to achieve it (the methodology).

While there are positive trends within the research on the effectiveness on project delivery, studies in the past 12 months continue to show that less than one-third of projects deliver on time, on budget or with alignment to the organisational strategy. If everyone was truly on the same page wouldn’t we expect a much higher project success rate?

So, here is our view.

Project management is often seen as common sense because, to us project folk, it is common sense and we often frame it in that context. At the same time, the concepts of project management are very easy to grasp and can seem obvious. Perhaps, when we talk about project management being common sense, we are talking about the concepts rather than the practicalities of implementation.

When we draw that distinction between the concepts – scope, planning, dependencies, risk management – and the practicalities – managing people, corporate navigation, priority juggling, creating momentum, stakeholder coordination – then project management feels less like common sense. The skills, experience and ability to deal with these day to day challenges are, in our opinion, not common.

Why do we care?

It is, as we said above, for good reason that a lot of project management is about creating commonality. The ability to create that commonality is a key factor is making projects successful. When we talk about change management, engagement, and communications this is one of the key things that we are trying to achieve.

And it is much harder to achieve if the starting position is “this is just common sense”. That statement comes with implicit assumptions about how much people know, how much time needs to be put in to creating the commonality, and the skills and experience needed to do it. If our starting point is that we are doing something that is either not common or not common to everyone involved then, in theory, we should be giving more thought to how we make it common and increase the chances of the project being successful.

Our conclusion is that, overall, project management is not common sense and, particularly at the beginning of a project, it is highly unlikely that what needs to be done is common sense to everyone involved. By the end of the seminar 80% of the audience agreed.

In the next part, we’ll give you our top tips on how to create common sense on your project.

/por