Whether you're a novice or an expert. Reports are the only insights we have as to whether a project is on or off track. Think of your project reports as the window to the performance of the project and your project managers. But, imagine the window is dirty, foggy or too high to see everything inside? who determines what kind of window and how large, small or when you can access it. The reporting structure, therefore, is one of the most critical bloodlines of the PMO and project controls remit. As a PMO professional now for some 15 years, I've seen all sorts of project reporting styles. There's big and small, round and square, long and short. End of the day though, it doesn't really matter how big or fantastic your reporting is. You may have the flashiest, brightest and most interactive report card, but if the there is an element of fault with reporting with images, it is this...
I'm afraid so when it comes to reporting. Departments lie. Ok, maybe not lie. They omit, fudge, balance and stretch the truth. So why do they do this? It's not uncommon to think that organisations culture has some element to the root cause, but usually, it can be as simple as blurred lines of accountability and reinforcement of job descriptions, job roles and expectations. It could be to do with changing requirements or the maturity of the reporting tools adopted. There is an endless list of ingredients for poor reporting. The path to navigate genuine trends and false positives are tricky. Its a bit like sailing, all is well until you hit the storm and waves push you from side to side, you make for a small island, with nothing but a small lighthouse to guide you from smashing your ship upon the rocks and killing all your men. You cant rely on your eyesight alone, you must use the sea, the wind and the crew to understand what is and what is not achievable. Sometimes a straight line will not do. This is certainly true on large and complex projects.
It's a precarious position as PMO to seek the truth and sometimes puts PMO managers right in the firing line, as report quality should be a PMO staple. Sadly integrating inputs from various departments across hundreds maybe thousands of data sets each month, can leave a lot to be desired in the quality-check-act effort. Truth is most PMO's have a hard enough time getting valuable inputs for schedule and costs before even worrying about outputs. But outputs matter. It is the map in which we all must agree is the best marker of truth. This influences decisions at all levels, therefore getting it wrong will not make you very popular.
So how does one do it? How do you see the forest for the trees so to speak? It takes an eager eye, attention to detail and above all else dedicated time. Allocating the right amount of time and setting up adequate opportunities for senior management to review is critical to this month end flow. Jeff Bezos (Founder of Amazon) apparently refuses to have any charts, visuals or any graphics of any sort in his reports. He and his team will sit through a maximum six-page report, they will all be given time at the start of the meeting to craft questions and study the material. This period is silent and builds trust and crafts far better and higher quality questions. I'm not saying this is right for all projects, but certainly is food for thought. I'm not sure if this is an urban myth however of the Amazon prescription. So here are a few tips to get your report reading abilities up.
Understand What you are looking for
Whether you know it or not, you should. There are only a handful of project data sets that I look at and can tell you whether that project is ahead, behind, full of shit or on their way to victory. I can tell you whether its an internal or client-side issue. I can tell you what is driving decisions, treatment and estimate where it will be in 6-12 months. Now I didn't learn these spider-sense abilities overnight. This takes years of looking at the same measures across different types of fo projects over an extended period of time.
Organise a list. Work out the following in the following order.
Time - Schedule Slippage
Cost - financial inflation
Quality - non-compliance volume
Change - impacts to the scope root cause
Risk - contingency burn down and risk exposure growth
Once you've worked out the 'what' you need to understand the 'how' and usually this will be in the form of working with the companies existing enterprise systems. Avoid making your own custom spreadsheets or bespoke tools, as this is generally not scalable and gives you more work.
Taking it slow, then spreading up as you and your team get use to the measures above is key. Putting in conditional and exception filters (those that trip a threshold) is the way to easily read through as report fast. In general, you should be looking for those measures above that have a 'negative' impact or potential impact on the business. Then use a heuristic or parametric qualifier to understand more about drivers and which way it is going.
Generally speaking, most reports are doing one of the three things below:
Tracking - monitoring the volume, output, throughput, lead time etc
Trending - reviewing the tracking information above against previous months, quarters, years etc
Tracing - involves looking at projection based on past consumption such as in burndown charts for throughput, finite assets and consumables etc
For me the rest of reporting is noise, this is how it needs to be. Get the moving parts correct, then start looking about how you would internally visualise this with your team and stakeholders/customers.
The Clue is Written
Ok, so now you know 'how' and the 'what' which are too very key reporting elements. Without these, there is no way of peeping through that window and understand just where you are at. But now we get to the most crucial. an influential part of my report reading post. Narrative and commentary have the ability to build or destroy projects. And just like the 'how' and the 'what' it can be manipulated, big words and acronyms used, limited wording or commercial wording to misrepresent the delay, trend, or information you've so painstakingly ensured was correct before it went to the print.
Project Managers to CEO's are guilty of this. Thus there is far more emphasis now on why something is going south. Why is the project appearing to be slipping? Why are costs continually going up? Why am I surprised month on month! If I've learned anything, executives hate surprises. So they should. Surprises are not something that should be happening on projects, after all we have our planning team, our design team, engineers, finance, commercial etc. How could it be a complete surprise to everyone?
Unfortunately tracking narrative is a lot harder. Reporting structures and reports generally only allow a small amount and the word is often overlooked, or factored by commercial before going to the client. Whilst this might be acceptable it certainly causes problems if the narrative being told does not line up with the data. Data and narrative must live in harmony. Should they not and it raises further questions. Hence its a very good tale for telling whether or not the accountable part knows what and how the problem occurred and why. The why usually also should be followed up with another 'what'. As in what are you going to do about it? This statement alone is very powerful and should be encouraged on all projects. The most common narrative is the one in which describes the drivers and what is happening. My next point would be 'so what'. That is what is happening now and I understand the drivers. So what will you do about it? Sometimes there is silence. Sometimes the subject is changed, but you'll know whether or not there is a control or no control thus signifying what type of action you should take.
Good luck, and remember tales come with experience, so make reports work for you. Disrupt the organisation if reports are not insightful or too busy, or too bright. If they are not working call it out.