** This original article was previously published on the magazine Mechatronica & Machinebouw, edition no.7, on October 28, 2016. The original article file can be found here. **
The essence of project management
In his book The complete project manager, Roel Wessels went searching for the essence of project management and agile leadership. An overview.
“I’ll definitely use it for the next project.” How often do you find yourself saying something along these lines? Let me be the first to admit that I’ve said it many times. I had just finished an interesting book about project management or leadership, but because of time constraints or that good old comfort zone, I never actually got around to applying what I’d learned. Besides that, it’s all well and good to be inspired by reading about the what and the why, but how on Earth was I supposed to implement those things into my own work process?
These days, you don’t have to be a project manager to be responsible for a project’s results. In a way, all knowledge workers are project managers to some extent: they are each responsible for their own tasks, they have to keep track of multiple projects at once, they are part of an autonomous team or they are expected to implement a shared methodology as a competence owner. All that autonomy is great, but it certainly comes at a cost. Instead of relying on “management,” you have to be your own leader and manage yourself and your environment.
From manager to influencer
Managing your environment poses a number of challenges, which I call the “&-&-& paradoxes” because they often concern the realisation of and-and-and. Three of these top the list of any “project-managing” knowledge worker:
1. Doing more with less
2. Giving your team space while still making the deadline
3. Seeing uncertainties and still making a commitment
“Doing more with less” is something we are all familiar with: we have to finish projects with smaller budgets and in less time, while also adding a bit of additional functionality and flexibly dealing with the many disruptions along the way. You are probably familiar with “Giving space and making deadlines” as well. We want the freedom to do our work as we see fit, while supervisors are simultaneously expected to manage the project closely to ensure the desired results are realised. Lastly, modern projects are rife with uncertainties. Waiting until these are resolved is usually not an option or does not result in sufficient added certainty. Thus it’s important to manage expectations, choose a direction and create progress despite the uncertainties that plague the project.
The &-&-& paradox requires mastery of methods and, especially, the right kind of leadership and behaviour. I would even go so far as to say that “neatly” controlling your project is not enough to be successful, because many project dilemmas cannot be resolved in any methodical manner. Instead of a manager, you have to become an influencer: rather than accepting the difficult circumstances you find yourself in, you create your own circumstances.
Many knowledge workers are unsure whether they have it in them to become influencers. In my book The complete project manager, I therefore searched for the essence of project management and agile leadership. Back to basics, because understanding those will make it easier to implement these methods into your own behaviour. Furthermore, it helps knowledge workers from various fields to speak the same (project) management language without having to learn an entirely new language. After all, many already possess the essence without even realising it.
Let us focus on several illustrations of that essence. The first might seem a bit obvious, yet it can be a real eye-opener even for experienced project managers. In any project, the goal is to realise the project result – but what do you do during the long period of time leading up to that final moment? Show action! Be visible to all stakeholders, because visibility breeds trust, feedback and opportunities to exert your influence!
So far, so good. Still, this approach often goes wrong because we are conditioned to come up with solutions and hold off on communication until we’ve done that: “I’ll show off my work when it is done, when all variations are known, when I fully understand the situation at hand, when all problems are resolved, when the design has been perfected, etcetera.” In all these scenarios, you are actually waiting too long. Focus and wanting to do a good job are great, but they can also lead to tunnel vision.
Traditional versus Agile, where nine functions are incrementally designed (D), realised (R) and tested (T)
How can you avoid this pitfall? I came up with the ten-percent confrontation rule for myself, which helps me avoid submarine behaviour. This occurs when you “dive under” at the start of an activity, work hard and only “resurface” at the very end, once everything is done. That means there is zero coordination with stakeholders during the activity itself. You can avoid submarine behaviour by making a commitment at the start of the activity to “surface” after circa ten percent of the lead time and show off an interim result at that time.
It’s important to understand that this moment is not free of obligation. Instead of waiting to see if you have anything to show, you make a commitment beforehand that you definitely will have something. That can be exciting, because you’ll often have no idea what you can communicate beforehand. Don’t worry, you will. The commitment you make forces you to create an overview immediately and identify the key (proactive) aspects.
The interesting thing about the ten-percent confrontation moment is that you not only avoid procrastination, but also surprise your client with your early result. That, in turn, puts them in a more cooperative mindset and creates a sense of “us” rather than “you versus them” (which commonly occurs when the deadline approaches and the pressure begins to mount). Best of all, whatever you come up with at the ten-percent moment need not be perfect, because no one will expect a final result at that stage. By showing daring and confronting early, you create an environment of open collaboration in which it is okay to be creative and make mistakes. Talk about influence.
A key difference between Agile and the more traditional (waterfall) project approach has to do with project management. In a traditional project, the scope is often set in stone. If there are any setbacks or changes, the project is automatically delayed and there is increased pressure on execution and quality. Meanwhile, an Agile project is based on multiple iterations (called sprints), in which time money and quality are a given. Although the scope is certainly important, it is negotiable based on priority. If there are setbacks along the way, the least essential functions will be pushed to the next sprint.
A focus on quality is emphasised because iterations must result in functioning interim results, bearing in mind the above-mentioned importance of visibility and feedback. Working in brief iterations offers another advantage: Agile expects changes to occur and the scope can be adjusted per iteration. One rule that cannot be broken is that once an iteration is underway, no more changes can be made. This method combines flexibility with team efficiency.
In addition to the standard cadence of iterations, Agile also has a daily rhythm: the daily stand-up meeting during which team members coordinate their activities with each other. With this daily meeting, the clear priorities with regard to functionality (via the product backlog) and the immediate evaluation of interim results, it becomes possible to give the development team a lot of mandate. In other words, Agile facilitates flexibility and offers a framework within which a team can operate autonomously.
Using the Agile method is as simple as using your common sense. Nothing is stopping you from implementing these elements in a traditional project organisation. In the end, what makes a difference is not the method, but the one applying it.
I often illustrate this by using the example of the TomTom navigation system. It excels at flexibility and showing action, starting at the very beginning of your trip. If you as the driver (client) do not set a destination, the TomTom (project manager) will not sit around sulking about not being involved in the project. Instead, it will do what it can: show you where you are. Once you enter an address, it makes a commitment without any hard feelings and shows you the path to your final goal as well as how long it will take to get there. The best thing about it is that it won’t get angry when you frequently deviate from the projected path; instead, it quietly informs you of the consequences of the deviation and how far you currently are from your goal. Replanning and coordinating are facts of life.
As a project manager, you should adopt a similar approach. Instead of desperately clinging to your plan, you must learn to look ahead towards the goal with genuine interest at all times – just like your TomTom – and continuously determine and communicate the optimal path to get there. Changes are implemented on the fly to avoid these accumulating and ultimately becoming a major issue. That’s what agile behaviour is all about.
I am a proponent of close integration between project management and system engineering. Structuring your work is extremely important; it gives you an overview of what to do and reduces the project’s complexity. You should therefore draw up a proper product breakdown structure (PBS) and ensure it reflects both the technical and organisational aspects of the project. Although it’s an underappreciated tool, the PBS is extremely useful for visually mapping out interim results and the scope of a project as a team.
Once this foundation is in place, you can move on to execution. What should you look out for during this phase? The critical parameters are the product elements to be developed that determine the final result. These can include technical aspects such as production output, system accuracy, energy usage and cost price, as well as non-technical aspects such as client satisfaction, the competence of your team and the client’s response time if you have any questions. Focusing on the critical parameters (usually leading indicators) therefore involves much more than just time and money (usually lagging indicators). A true professional knows what the critical parameters are, ensures they are closely monitored throughout the entire project and implements course corrections long before the test phase begins.
Project management is mostly about taking your job seriously. During the execution phase, that is done with the heartbeat- similar to a ten-kilometre race in ice skating. Like a project, this competition could become confusing and boring. The reason it absolutely isn’t stems from the fact that we see the ten kilometres as twenty-five clear four hundred-metre laps. The athlete has a lap time schedule (the plan) and therefore knows exactly what to achieve during each individual lap. This gives the athlete peace of mind and allows them to focus on substance and technique. The crowd also understands perfectly well what a good lap time is. For many Dutch people, seeing a skater accelerate near the end of a race and push his lap times into the “low thirties” is a reason to get very excited indeed.
For the athlete, a four hundred-metre lap is like the PDCA cycle period (Plan-Do-Check-Act) for a project manager. You should therefore divide your project into a series of PDCA periods and clarify what has to be realised during each cycle (activities, results and progress with regard to the critical parameters). The constant project heartbeat leads to coordination, visibility and feedback and will put the entire project environment in the right flow like a flywheel. From the very first moment, you as a project manager, your team and your stakeholders are involved in a countdown to the finish line. Driving this project heartbeat requires initiative and perseverance, because a flywheel never spins at full speed from the get-go. In other words, you must work for the PDCA before the PDCA can start working for you.
Embrace the essence: show action and take charge, be flexible and goal-oriented like a TomTom, implement structure and reduce complexity, focus on the critical parameters, drive the heartbeat and – above all – enjoy yourself. Project management is fun!
Roel Wessels is the author of The Complete Project Manager, a book about ‘the how’ of project management and how you as a project manager can stay in control, even during difficult situations, by adopting a proactive attitude. Roel works at Holland Innovative, an organisation that specialises in project management, product and process development and reliability engineering. Prior to this, he worked at Assembléon, Ordina, Vanderlande, Philips and DAF, among others.
Editor: Nieke Roos
Click here for more information on the Project Management Masterclass
Click here for more information on the book The Complete Project Manager