As a consultant, I work with clients in a variety of IT projects and roles. It is common to find oneself in a complex environment that one has to learn how to navigate. I have been reflecting on my learnings, particularly regarding projects that I am involved with at multiple levels, from management to writing code.
Find the right people to talk to
If you are starting a project with a high level of uncertainty, you will want to start by creating an overview. Gather all the available material and create a stakeholder or project overview that you can refer to when aligning priorities with your direct client. In hierarchical organisations, you will usually also find an organisational chart to help identify structures and project set-ups.
The following image shows a very rudimentary description of people and projects. The arrows show the connection between our project and the neighbouring projects (e.g. Project Pen or Project Flower). Normally I would write the name and role of the person in the boxes:
Of course, the diagram is fluid: new decisions may affect the connection to a project. New stakeholders might become more important. People might leave projects, or projects might be reorganised. Also, there is no "one way" to approach this. The chart can have different views. For example, I once had a situation where we had to manoeuvre our project through a very political situation, so we put green, yellow and red dots on people to keep track of our communication with individuals.
The main goal is to create transparency and easy alignment with your project team. This allows you to plan specific communication actions and helps you to understand the roles of existing projects. The goals of other projects (e.g. what might a collaboration look like?) may become clearer.
Find the right abstraction layer
A project is not one-dimensional. It is not just a presentation to management to get the budget approved. It is not just the technical implementation. And it is not just the product specifications. There are different ways of looking at the project scope and requirements. As I support on all layers, e.g. management, architecture and coding layer, I found it extremely important to find the most effective layer and stick to it.
You may define your own set of layers that help with leading questions. Here are some notes from my differentiations:
- Product layer: What is the value we create? Who are our end users? Why should others use our product?
- Management layer: Who will own the project in a year's time? What are our next milestones? How much budget do we need to continue?
- Technical layer: What are our technical interfaces? What are the components of our architecture? What programming languages are we using?
Layers can vary. If I were to write more code, I would also get into a coding layer: what do we need to implement to prove our architecture? What code do we need to write to demonstrate our MVP functionality?
Thinking in layers allows you to reduce complexity and better assess what your project needs most right now. Is the value proposition clear to everyone? Is the budget realistic? Do we need to demonstrate feasibility through technical implementation? Questions like these can guide you to the next steps that will have the greatest impact and be the best use of your time. Conversely, it would not help to have the most visually appealing technical demonstration if none of your stakeholders understand the business value of the project.
Parallelise Streams
Do not bet on a single horse, I learned it the hard way: after the first iteration we proposed a continuation of our project to management and got funding for a project plan approved. However, our collaboration was based on only one project, on whose success we were apparently too confident, because that one project collapsed in the second week after the start of our 6-month project iteration (which we had based on collaboration with that project).
After a panicky search for our other project collaboration options, we ended up with seven parallel project streams again. This was too much for our three-person team. However, after some assessment, we ended up with a handful again, which was totally manageable and would spread our risk across multiple project collaborations.
We and I have learnt the hard way to parallelise project streams. This reduces risk, because project dependencies can always fail or lead in an unwanted direction. More options give you more freedom to steer and shape your own vision.
Create Transparency by Sharing Progress and Thoughts
As discussed, we are taking about a project that is complex in the sense that business requirements are not yet defined. The end users have not yet been fully identified. So it is crucial to create transparency about what you are working on. At least this is how I would build trust for myself: keep others informed about what has happened during the week and share thoughts about it. Thoughts could be potential risks I see or certain priorities we should focus on (from my point of view).
I would write these notes once a week and share them with my client and my internal delivery coaching team (e.g. consultants supporting my engagement). I also found that the right channel was important. Initially, I sent them by email without getting much response. After a while, I switched to our chat tool and just chatted my notes, which worked much better. It gives people a chance to react and comment on my weekly notes. It also gives me confidence and feedback that the points I have raised and will raise are the right ones.