About The Author
Kenneth Madsen 1 article
Residence: DK Aarhus V, Central Region
Senior Project Manager (MBA, CSM, CGB) - Project Management | Supply Chain | People Management | Futurist

more about Kenneth

All Authors


The Unified Project Management Dictionary

Configuration Management System

Configuration Management System is a set of procedures and/or tool that serves as a subsystem of the top-level project management system, and it is used to track, monitor and control changes to project artifacts.

more terms

The Art and the Tricks of Project Management

10+ years into being a Project Manager, I have been reflecting a lot on the function, the business, the general practice of conducting project management. Part of this of course comes from many years of working in this field, but also the role as Senior Project Manager I have eased into over the last years. Sparring and mentoring younger colleagues, or simply colleagues with less experience, are eye-opening activities in many regards. Someone once said something along the lines of "to improve above a certain level, you need to teach your craft to someone else" and I believe this is very true. Filtering questions on a subject or process through the prism of your own experience and knowledge is both an excellent way to revisit specific knowledge and improve on it, but also sometimes (often even?) to rethink and relearn what you thought you already knew, because applying it to a new situation will often require using your knowledge or skill in a different manner. 

 Anyways, I would like to summarize my hard-earned experience in an easy-to-use format that (hopefully) can be food for thought for the interested reader, so here goes.


Soft Skills Are Hardcore As a project manager you have direct interactions with a lot of people and depending upon your organizations setup, your project team will become close colleagues over the course of a project’s life time. This of course means you will be doing indirect leadership every day and quite often you will have more interaction time with the project members than their immediate line manager. Also sometimes known as “leadership without mandate”, what you do every day is to get people to see a common, unified goal and working towards it. Doing THAT involves the whole plethora of so-called soft skills, which I would claim are alpha and omega when it comes to creating momentum and common understanding in a project.

To me, the soft skills can be broken down into four main areas that each has a long list of skills associated (what I list under each is by no means exhaustive). THIS is the actual glue that keeps a team together and builds a project organization. The four areas are: Communication Skills (e.g. listening, negotiation, storytelling, presentation and public speaking), Critical Thinking (e.g. creativity, critical thinking and problem solving, adaptability), Leadership (e.g. conflict handling, facilitation, clear feedback, leadership, project management and mentoring) and Teamwork (e.g. networking, establishing relationships, intercultural competences and persuasion).

 Even though a project might ultimately deliver a wind turbine, a mobile phone or any piece of technical equipment, all of this is being done by people and it is through people the project succeed; the skills needed to create the best possible connection with the people you work through, are the most important place to focus your time and energy if you need to get better at it. And actually, even when you get better, don’t stop focusing on this, as there is always something more to learn :)


Relationships Are the Gateway to All Things Good In direct extension of soft skills, it should come as no surprise that relationships are the gateway to all things good. It goes without saying that as a project manager you need to be on good footing with your immediate project team to be sure that an understanding of common approach exists – but relationships to stakeholders and senior management are just as important. A lot of the outwards pressure on projects come from those two areas and people who do not feel they are sufficiently informed or that you do not understand the criteria they have for achieving a success. Yes it’s true – you have to deliver on time, on spec, on budget and on agreed quality – but you also have to work on and manage those expectations. Understanding your stakeholders and building rapport with them is not something done in one day – at least I have never seen it done that fast :) But building a long-term relationship and keeping contact is a very good investment of time. It will frequently also be part of your upwards management effort.


Communication is the Prime Deliverable until the Project Itself is Delivered Information from the project – good as well as bad – should be viewed as an asset – it is the main deliverable until the project proper itself is delivered. The winning formula in my experience seems to be: Frequent, Predictable (in both form, length and so on) and Accurate. Especially the last part – in both individuals and organisations, there can be a tendency to gloss things over, to not talk about what doesn’t go as planned, to only want to report green lights across the board. In my mind, this is both dishonest, counterproductive and plain stupid. Get the facts out in the open – both the good and the bad (or maybe “unwanted” is a better term) – inform of both and in particular, inform where both will lead.

A positive result is not an end delivery – it should lead to the next step. A negative result should be addressed with the actions taken to correct or negate it. Communication – both verbal and written – is something you have to practise to get good at. But in my experience, if you keep your message on point and driven by facts, you will do well. No need to write long fables or wrap everything in tech or management babble – deliver the essentials. If anyone wants something expanded upon, they will ask for it.


The Small Tricks of the Trade

Apart from having an overall project time table, knowing your deliverables and the critical path and what risks to mitigate how and when (the standard PM stuff) there are a few additionals I would call “the tricks of the trade” – the small activities, or tricks if you will, that will help you a great deal.


Obstacle Removal Inc: One of the primary activities I see a project manager as having, is the removal of obstacles – this is an idea I have assimilated from my past working as a Scrum Master. This is both for the project in general but in particular when it comes to the project team. As a PM you work through others, so helping those people be able to do their job is just common sense. This can be a matter of clarifying priorities with a line manager, getting the resources needed to look into a derived task or any other of a million smaller things. It will also be the very best tool for building trust with a new team – when you go to bat for someone, it is the best demonstration you can give of your belief in and support of that person(s).


The 24-hour 15-minutes Status Meeting: This is another element I have lifted from Scrum and I can only recommend this for the information sharing and helping the team to see the same playing field and objectives. Every 24 hours (preferably in the morning) assemble your team. If you are running a project organisation with several project managers facilitating work streams, let these teams meet first so the PMs have the latest information as you meet. You basically just form a circle and let each member answer these 3 questions: 1) “what have I (or my team) worked on since yesterday”, 2) “what am I (or my team) working on today” and 3) “do I (or my team) have any obstacles?” You immediately get an overview if the direction of effort is as agreed but also get an early warning on obstacles. This can be anything from a task being more difficult than expected to someone creating opposition somewhere in the organisation. Also makes it easy to determine who will focus on removing that obstacle and get an update on progress the next day.

I can only recommend taking some notes on this to have a written record tracking progress and obstacles. Those familiar with Scrum will recognise that this is the typical burndown meeting in a specialized form.


Upwards Management: This has become all the rage in books on the project management field but I think anyone who has worked with this area for some years will recognize that it’s not enough to manage the project and your project team – you also have to manage upwards; expectations, deliverables, knowledge and so on.

As I already said under “Relationships Are the Gateway to All Things Good” you need to work on the relationships that goes upwards in your organisation too. As a rule of thumb – if you are using less than 40% of your time in this direction, you are adding unnecessarily to your risk landscape. Catching the signals and having an opportunity to affect the way opinions are formed – this should not be underestimated in value and importance!


Create a Visual Cockpit: Having a physical representation of the status of your project team is a very good investment of time and effort. Have an overview of current sprint and timebox, overall time schedule with Gateways or other major mile stones, top risks and anything else that is good for quickly and effectively share the status of the project. It’s of course also good to have this same information shared in a similar format on whatever platform the company uses for intranet services – especially if not everyone is in the same location. This is good for two purposes: 1) it’s a physical reminder for the team itself and a way to see and be reminded of progress, focus areas and any impediments. And 2) There is always an interest from those not directly involved in the day-to-day of the project (all levels of management comes to mind ahem ahem) be it stakeholders and otherwise.

The value of being able to demonstrate/show&tell that the project is alive and well and give a quick overview of major points can offer HUGE value on both satisfying general legitimate curiosity AND cutting down on the noise generation to the tune of “we don’t know what they are doing so they are probably not doing anything” that sometimes occurs in organisations.


Risks, Issues & Escalation – Everything Is Not Always OK: Especially when starting out as a Project Manager, there is a tendency that you want everything to look good and act under the impression that if anyone finds out that there are any issues you are not doing your job AND you should always be able to handle things on your own. Not true at all! As also noted under “Communication is the Prime Deliverable until the Project Itself is Delivered” it’s far better to get the issues into the open. In fact, if you have an organisation that believes everything should always be in “condition green” and under control, you might want to take a look at the culture and consider if that is a place you want to work in the long term (I kid you not).

The trick here is to carry out an ongoing evaluation, assign mitigation actions and of course track progress. That which cannot be solved in the project team and which requires attention, get that to the proper people at the proper level who can help. Do NOT escalate issues higher in the organisation than necessary – this is the sure way to get unwanted and unneeded attention; attention you might frankly need at a later time for real issues. Don’t be the project manager who shouted wolf! :) If you have a high-value risk that involves one or more stakeholders, of course also keep them informed – they don’t need to learn about this in a random manner. I also highly recommend that in whatever reporting format you use, include every time an overview of the top risks, what they will do if left untreated, what your mitigating actions are and when you expect to have a changed status. That way, if anyone who receives the reporting have questions, they know where to go.


The Steering Committee: Last thing I will go into for this article is the Steering Committee or SteCo. The manning of this is sometimes a thing you have influence on as a PM and at other times it will be dictated by the type or nature of the project. Chairing the SteCo should be the project sponsor or someone similar with organisation seniority and pull to be able to make decisions that may not be shared by all SteCo members. In my experience, the SteCo should do primarily two things: 1) Give Strategic Direction and 2) Support the Project Manager.

To Give Strategic Direction (I.e. decisions on issues, changes due to things ongoing in the organisation, etc) you as a PM need to make sure the SteCo is informed of the status of the project and understand the steps being taken and so on. Any reporting you do also serve as a very important tool to not only tell of what has happened and any critical issues, but also give a forecast of the highlights of the coming month (deliverables, gates, transition to operations, etc) as well as any risk elements that may become active.

To Support the Project Manager, is to me about making sure you as a PM has the resources needed to carry out your work, general assistance with resistance within the matrix organisation where you likely operate and of course also make sure you have the necessary authority to execute the project. There can be a tendency for SteCos to want to micromanage the project and seek a degree of control that should reside with the project manager. In my experience, this is often done with the best of intentions due to the importance and impact of the project. However, as they say, the road to Hell is paved with good intentions and it does not change the fact, that YOU as a PM need to have the authority to execute the project.

A few good ground rules to establish with the SteCo can also be: 1) Are some deadlines or milestones allowed to change without involving the SteCo? 2) What parameters does the budget operate under? (no changes, +/- some %, what?) and 3) How are scope changes handled? (almost all projects I have ever run have had some sort of change – unclear rules on how to handle these will come back to bite you).

Published at pmmagazine.net with the consent of Kenneth Madsen
Source of the article: {Linkedin} on [2019-01-15]