Lately I have had several situations and conversations that led to the same topic: the importance of the basics, the foundations, and how many headaches we could avoid by paying a bit more of attention to them. The funny part was that it was not constrained to either professional or personal contexts, it was in both. But I am getting ahead of myself. For illustration purposes and because I think examples may resonate with more than one reader, let me share some of them with you. Let´s set the scene: a large-scale project to deploy IT software.

Part of my job has been deeply tighted to project management since more than 8 years ago. The topic, the size, the company, the language (if you are working in international environments), and the outcomes may vary, but the essence is still the same: you have a goal, contributors with varied ranges of active participation, tasks to be done in order to accomplish the project, risks to be managed, etc. Recently I was invited to a project management meeting of a large transformational project with some of its top responsibles. I was looking forward to witness how they would tackle some pressing issues.

And guess what: I was also disappointed. One of the 'magical' solutions turned to be another fancy Excel with a list of tasks to track, categorised around a new set of criteria. By then, I had lost count of how many lists of that sort we had already. And that kept me thinking. As dumb and basic as it may seem, this last experience confirmed that the questions that keep consuming additional efforts, time, resources (as if they were not already limited) are some as obvious as:

• Do we have the right functions involved? Do we know which teams are representing those functions? Do we have the right people within those teams? Are the scopes of each function/team/role explicitly defined in clear terms, coherent and understood?
• What we are searching to accomplish (hint: be SMART), is it understood by everyone?
• Is there a single source of truth where the structural information can be consulted when in doubt? (This actually can liaise very well with some Enterprise Architecture thoughts I´m working on… so stay tuned!)
• Do we all share the same definitions for the core concepts involved in the project? For example, imagine you are deploying a solution across several markets… is everyone sharing the same understanding of what 'market'means (legal entity? country? main country plus smaller countries in the area? others?)? Trust me, when functions as diverse as legal, finance, commercial, and IT are put together, there is a high chance they have their own definitions. The earlier you detect it and reach a common definition, the better. Best-case scenario, you will obtain full confidence on shared understanding; worst-case, well, hopefully you will still be able to learn and converge before major impacts hit.
• Do we have a clear checklist of approvals and gates that need to be accomplished in order to consider a phase or a milestone done? In other words, are the 'definition of done' and quality gates explicitly described, accesible for consultation and understood by the involved people?
• Are information channels properly established and used? Many times, the issue is not having a to-do list, but properly communicating it and keeping that as the single reference. Unfortunately, the temptation to create additional list is there, which only create more confusion for the participants because at the end of the day it is not clear which list 'is the good one'. Imagine the chaos for those trying to understand the status of the project versus the frustration of the implementation teams no longer knowing what are they expected to do or feeling the scope is continuously changing.
• Do we have a retrofeedback channel to collect feedback, learn and improve the delivery? This may not sound relevant, but believe me, in a large-scale project, where delivery is phased in waves, you have a mine of gold between your hands if you include feedback sessions in your plan to compare expected outcomes and real outcomes, ask the end users, and integrate the learned lessons in the next-coming waves. Sure, you can always ignore it and then just let the issues become a snowball and dedicate additional resources to, now yes, understand the root cause, mitigate and solve.

So now I can rescue my openning : 'the importance of the basics, the foundations, and how many headaches we could avoid by paying a bit more of attention to them.' What all of these examples have in common? The questions I mentioned, none of them were rocket science. Actually, once you take some time to think, they are pretty obvious… so obvious that they are easily assumed. And that is the big mistake.

I have reserved this element until now, but we cannot ignore the presence of AI. With the World searching to extract more and more value from AI, by intertwining it with our daily activities, we have an additional responsibility to ensure the bases and the ground rules are clear. Playing some scenarios, let´s imagine the previous questions now with a touch of AI in them, what could be the consequences:

• An AI-powered assistant offering guidance to the deployment teams about the quality gates they are expected to fulfil… and being grounded on all the activities lists, polluting its answer and spreading incorrect information without the acknowledgement of the project management team until the status evaluation comes.
• AI used to help craft or finetune requirements when the relevant context and/or scope is not clear: processes defined with multiple names and interpretations, tools under the transformation not following a unique name, organisational scope mixing criterias, etc. You may end with a wonderful and comprehensive list of requirements, but are they really taylored to the goals of the project? Are they all relevant?
• AI and automation used to automatically update some tracking tool… if the source of that information is not grounded on a clear framework and governance. Instead of helping, this smart automation will be just the origin of another set of inconsistencies that would need to double check and rectify. Wouldn´t it be easier to just do things right since the beginning?

Here are my two cents:

• If you are on a leader/decider position: your position may give you access to information that may be basic for you but not cascaded to the teams, sometimes you risk being in an Ivory Tower… and that means isolation. Ensure there is a backbone where all contributors can rely on, and emsure the expertise coming from the ground teams is well heard.
• If you are on the follower position: if something is not clear, you spot inconsistencies, you miss some key points, you think something is not feasible… then ask questions, communicate, raise your hand. The earlier those points are treated (responses can range from a simple confirmation or update of a document to deeper analysis of impacts because a key requirement was forgotten) the better: it will save time, frustrations, efforts, unnecessary complications.

I oversimplified on purpose the two precedent points, but the message is still there: big projects require a team work like a Swiss clock, every piece has its contribution. Ensure are given the right tools to perform your task and help others perform theirs.