This post will be a little bit more “roaming through knowledge” than the usual.
Actually, it is part of a series, first published in May 2009.
But, following the dictum of somebody else, I will make things as simple as possible, but not simpler.
What is the point? Talking about ways of representing and forecasting the expected decisions of groups and individuals, and some projects that try to build a “model” of what we are and could be- be it our DNA or our brain.
And, while doing this, recalling some useful concepts that you can apply in whatever you do in your business and personal life- including when you are on the receiving end of the results of a model.
As usual- theory is converted into (hopefully) plain English, and the examples are from real life and experience in business, politics, technology- and their impact on personal and business life.
PREVIOUSLY
GMN2009: PLANNING
In my definition, a plan is neither cast in stone, nor just an intellectual exercise done because it is supposed to be done.
But what, after defining a model of your reality, and identifying the changes required and their impacts, should be part of your planning activity?
GMN2009: PROGRESS
You do not need to know just what you are supposed to do, but also where you are, and where you should be.
If you are a perfect project manager with all the certifications required: probably you should skip this section, as it could be depressingly simple.
But it is not just progress itself- is the measuring and definition of progress that matter.
Models (see GMN2009: MODELS), introducing or managing a change (see GMN2009: CHANGE), or a project that has a plan (see GMN2009: PLANNING): progress is always toward something that you already defined.
If you do not set a benchmark… you are just keeping a log, not measuring progress.
Incidentally, on keeping a log, the best approach that I suggest is to be pragmatic.
But we are in the XXI century- therefore, you cannot escape from the use of software tools for project management.
Do you use Microsoft Project? If you say yes, 90% of the time, you are lying. You should answer: some of it.
I had to design also the planning and progress report/forecasting part of methodologies, and, as I worked across different countries, industries, companies, and company sizes, for the last 20 years, I saw paper-, spreadsheet-, software-based planning.
Including some monster softwares that, before SAP and other ERP (Enterprise Resource Planning- in the origin, one size fits all software to replace all the corporate software needs), tried to control a company by controlling the scheduling of its activities, and converting any activity into a project.
What was wrong with that choice? That is was before CMMI and other methodological frameworks that tried to first understand the culture of a company, and then to match the tools with the culture.
The same applies with Microsoft Project.
It looks as a software built by programmers revising what the theoretical project manager should do.
Try to use all its features, and you will need full time staff devoted to feed the beast.
And then, process its reports; and then, give to the project manager a summary that, hopefully, has been done properly.
So that, in the best of cases, instead of managing resources, the project managers is two or three layers from reality and… resorts to intuition to manage, as the software would absorb too much time.
And you do not really need to fully use Microsoft Project or other similar tools to the full extent of their features, to monitor a project.
I proved that long, long ago, that also a multi-team project (actually, more a programme than a project, with tens of people in multiple locations), a spreadsheet and a a limited time is all that is needed.
My first experience was in the 1980s, using a simple Lotus 1-2-3 spreadsheet that I designed to do a weekly progress and forecast for my manager, on a multi-team, large project, for a banking general ledger.
But I was also a programmer (if you ask: COBOL, DL/I, CICS).
So, I had probably a couple of hours a week to collect the information by questioning people, and a couple of hours to type the data, review the results, chart the progress, and give the manager what was my assessment of the status.
Yes- questioning: somebody had the smart idea of introducing productivity by the number of lines written, as a Key Performance Indicator – KPI (search wikipedia for the details on the theory behind identifying few information as representative of the status of an activity vs. a pre-established reference).
I saw programs that could be written with 400 lines becoming few thousand lines behemots by… inserting useless code, or, for the laziest ones, just copying somebody else’s program inside their own, and then building a way to avoid using that code (the recordman? turned a tiny program into a 1000+ lines monster).
So- it is not just the way to log the progress. It is also what you consider a progress- KPI design.
If you want: KPIs should have a limited shelf-life, linked to specific targets and purposes.
When I see systems with 700 KPIs, that have been alive-and-kicking for years, and most of the time are at 100% satisfaction, I call than not a “progress report”, but a “production control”.
But using KPIs has another side-effect: somebody will ask to use yet another software to monitor and manage the KPIs.
One day, we were suggested from the head office to use a management software, that was similar in logic to what I said about Microsoft Project- actually, even worse, as it was in the pre-Windows times, and most “serious” softwares, also on PC, where designed with a rigid top-down logic.
If you are not so well versed in old computers, the approach at the time was: “unplug your brain, insert the memory bank containing everything that you were told at the training course, do not use any judgement, and just type the data in order required.”
And it was pre-MP3, so… it was really boring.
The side-effect? I was asked by the manager in charge of the control (I was still officially a junior mainframe programmer, at the time): which one is the less useful programmer in our team that could still be reliable?
The reason? Full-time number typing and crunching and reporting, requiring so much time, that everyone was required to provide so many details, as to make impossible to inquire on the actual information…
My way of using Microsoft Project and the like? Generally, slightly more than an Excel spreadsheet, except for the Gantt “ribbon report” (where we are vs where we should be).
When the project is complex, and there are multiple ways to s***w the budget and plan up, I also use the PERT (Program Evaluation and Review Technique) and CPM (critical path method), along with some radar chart to keep track of the real KPIs of each group of activities.
Why I chose these graphical approaches? It is easier to hide reality in a one foot high “number crunching” report than in a simple graphical chart.
Moreover, this graphical summaries are easier to use to discuss with any stakeholder, be it the people working in the team, those affected by its results, the buyer, the customer (not necessarily the same people), and so on.
It takes few minutes to explain (indirectly) the form, and the discuss the substance. Also if, sometimes, it takes a long, long time to identify the key information, structure it, and to do so without losing meaningful details.
But, in my view, certification certifies what can be quantified and structured; but project management is mainly communication, monitoring, coordination- with some maths here and there to help you through, not the other way around.
Oh, and why “indirectly“: we consultants every year, as more than a customer told me, invent something to justify our existence.
And I find that way too many of my brethren forgets that we are paid to do something, using skills that maybe are needed only once in a while and that we are supposed to have, not to show how brilliant we are in using something that nobody in the room understands…
For reasons related to the activities, the budget available, and the scarcity of people with the right mix of skills, I often had first to audit/monitor/support, then to manage multiple projects at the same time.
Despite what some of my colleagues said once in a while, I do not have the gift of being in two places at the same time.
Therefore, the secret to keep track and ensure the progress is a single concept: delegate and coach.
Or the other way around (it depends).
The approach is relatively simple.
You need to assess the team members involved, and then identify and delegate limited challenges to coach them on doing more than they expect to be able to do, but within the general framework.
While delegating new tasks, these will include also the production of the information required to monitor the progress.
But the way you actually have them help you to monitor the progress is something that should be adapted to the specific environment and “corporate culture” (what is normal in the environment).
There are still two other activities, that I referred to in the previous section (see GMN2009: PLANNING): keeping a log and collecting the progress where it happens.
The simplest method that I adopted long ago is to help people build a habit that is not linked to software.
If you ask people to prepare a report on what they are doing… you get anything from a new “War and Peace” to a single word describing the activity done.
Whenever I see that the team needs to learn how to track progress, I coach them on “logging” the activities done and planned.
If you are working in activities resulting in physical objects, you probably can ask your team to tell where they are- as most of the activities have procedures, pre-defined steps, and you can assess how long would take to do the remaining steps.
If you are working in services, including software writing, the typical sign is when you get a 20/50/70% estimate.
Activities are either done, or are not. If they are still in progress, what you can say is how much time you spent, not the completion rate- unless, of course, you have a benchmark.
The concept is anyway simple: if you teach people to build their monthly report on a daily basis, using the same tool (as any company now has a tool) that they will use, eventually they will build a habit, and you will be able to monitor the allocation of resources in real time- without asking.
As I wrote above: progress, as knowledge, should be collected and updated where it is generated, as a side-effect of the activity (for what concerns knowledge, look on BusinessFitnessMagazine, and read the “knowledge retention” issue).
There are some other positive project and activity management side-effects of building a “conditioned reflex” in people (I do- I report), but my logging approach will be described in a separate post, to be published after the end of this series.
Overall, having people used to keep track of what they are doing allow them also to identify what could happen- or see what is evolving in a way that is different from what they expected.
Checking the progress by constantly monitoring activities vs your original or revised planning is even easier, as you will be able to analyze not just what is happening now, but also what could be your future projection.
Because mapping progress is not just seeing where we are now, but what would happen if we were to keep using resources (time and others) and producing the outputs at this speed.
I plan to deliver the new (or changed) reality, while planning you also started thinking about what could go wrong.
You made some assumptions.
And you expected to generate some results.
Most modern project and activity management methodologies focus on “risks management”- to avoid that a risk becomes a reality.
But, frankly, a risk sometimes is coupled by an opportunity.
So, this brings back to the original point: no matter how well you think, strategise, organize, plan: any model that you build has to be aligned with reality- or identify what matters and what does not matter for the purpose of your model.
NEXT
GMN2009: RISK
If you identify the “risks”, what could affect the conditions that you assumed that could affect your execution of the plan, then you will end up monitoring that:
- you are using the resources identified if, when, how planned
- the risks you already decided to keep under control
- whatever new happens around you that could affect your plan
- last but not least: that the activity you planned for still makes sense
It is not just the journey that you have to keep in check; it is also the destination.
Tags: change, chart, coach, coaching, gmn2009, indicator, key, kpi, management, methodology, microsoft, model, monitor, monitoring, organization, performance, planning, progress, project, radar, resource