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: CHANGE
Any organization, or organized group, whatever its purpose and composition, has what could be defined a “decision inertia”.
Any change has multiple dimensions: time, the environment were the change is carried out, the “stakeholders” (to simplify: whoever, directly or indirectly, is involved, affected, interested by a decision), etc.
In this post, we will briefly see the multiple dimensions of change, and what means managing change.
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.
Planning is here assumed as: identify, with the resources available or expected, how and when the expect result will be produced, identifying also as much as possible what could impact on your plan.
I will assume that you have already built you own “model” of the target reality (see GMN2009: MODELS), and then decided which changes are part of the overall target.
And,of course, the general strategy to manage and generated the desidered outcomes (see GMN2009: CHANGE).
In early 1990s, when I started first managing my own area of business by building methodologies for customers of my employer, I had way too many meetings with other managers that started planning as soon as they had an idea of a project.
Why “idea of a project”? Well, if you have a title, and a requirement- that’s not a project charter.
A project charter gives you also the “boundaries” of your activities, and the expectation.
My approach was based on what I saw first when I was part of the planning of political activities, and then preparing the travels (and negotiate the related logistics- from travel, to… food rations!) in the Army.
Then, I expanded the approach when I worked for few years on DSS/EIS and related activities, after doing some studies and experiments on Expert Systems and decision making/modeling at the University.
The point is simple: when you are used to activities that have a physical aspect (e.g. laying out infrastructure), you know the difference between the idea of a project and a project.
Let’s say that you have decided to change the furniture of your main room.
Would you first buy the furniture, or first check the size of the room, and the uses that you want to do of that room?
I am willingly ignoring the budget. Because the budget sometimes is pre-defined, sometimes is negotiated after you understand what you need to do- but, without a clearly defined purpose and strategic framework of reference, the risk is that a project outlives it reason for existence, and evolves into a budget-consuming exercise.
As I discussed in GMN2009: CHANGE, the time needed to generate change and process feed-back is strictly related to the size of the organization involved.
No, not because of legal or organizational red-tape.
When defining a plan, a detail often overlooked by less experienced managers is that their project does not live in a vacuum.
Remember: no matter how many times it is renewed, a project is meant to begin and end (or be stopped before it ends), delivering some results- be it a new town, an MP3 player, a piece of software- or “just” a training curriculum.
The examples that I gave are chosen on purpose: each one of the projects delivers something that, to be really meaningful, has to be used, maintained.
And this bring about another often forgotten habit: have the project manager produce and discuss a “lessons learned” on the project. As soon as the project is closed, ideally using the “travel log” that (s)he kept during the project.
Only by joining the “now and here” information contained in the log with the “what happened and why” review of said information, a real “lessons learned” report can be produced.
Whenever I see a project that delivers a “lessons learned” by having the project manager sit down at a desk and “remember”- well, I look for the file on the project manager, as usually her/his profile tells you what you can expect to read.
But this will be discussed in further details in the GMN2009: PROGRESS and GMN2009: RISKS sections.
Interestingly, if you were to read the material from different standards (as PRINCE2, PMI, etc), you will see that defining the cost and planning the activities are just sketched.
And this is consistent with the tests to obtain the certification, that focus on the “formal”, “quantitative” side of management- as that is the only part that can be measured.
When, in early 1990s, I began my first major consulting assignment to define a methodology for a customer, we came to the point of discussing “planning”, starting with the “how” and “what” of budget definition.
I mean- how do you come to compute the cost and time, and what has to be used.
Focusing on Information Technology, the first item was discussing existing models.
The interesting part was: most models for planning were a typical example of what, while I was studying in London one Summer, I jokingly described to my professor as my view of economic models- really good at forecasting the past.
A small example.
If you travel to visit a place, say, in 1991, you do not expect to spend the same amount of money 10 years later.
The environment changes. The prices, of course, do change- and not necessarily because of the inflation: the “mix” of services and products available changes.
So, a wise tourist does not take her/his old “travel budget” and say: I am going now to do that: (s)he first checks if and what has changed that could affect not just the end value, but also the “parameters” used to compute.
I remember that one of the first model proposed was COCOMO. Interesting: each activity contained also part of the ancillary activities that nobody wants to do- like, documenting 
But something did not ring right about the options: looked as if they were build in the 1960s-1970s.
And, when I went to check the data used to build the model, I saw what I expected: the data used to build the model was representative of technologies and way of working that were definitely obsolete.
Flame to me about models- but, frankly, my view is quite simple.
The model was built assuming, from the results, what would be the process. And adding a mix of projects that was representative of the technologies and common wisdom at the time.
Three elements in defining a budget, that, in my experience, work everywhere:
- collect information on constraints: budget, cultural, technological, etc
- collect information on the resources available and their unused potential: human, technical, goodwill
- take the project information, at the level of knowledge available: bits and pieces, costs per unit, and so on
The concept is simple in my mind, but probably an example could help.
I remember the first time I helped to prepare a budget for a fixed-cost project, in 1986.
We did a hair-splitting exercise, by collecting the details available, building a general picture (the framework), and then adding all the details.
Then, we classified by level of complexity, and multiplied by the number that was currently used as a reference in our company (a large one- we had a number of project in any industry on any technology- when I asked the number, it was easy to quickly have it from the central office).
Finally, we multiplied.
And, of course, then it came the negotiation- that cut down the budget in half- and less
For the sake of completeness: our original budget was the right figure 
But what I did not know- I had no access to that information, as I was the new smart kid on the block, and working with the branch manager on behalf of a partner to plan a major project was already way over the head.
And probably, at the time, the only people who really read the contract were in the legal department.
Nobody noticed that the fixed-price project had a tiny clause: about being invoiced back for the use of the computing resources of the customer.
The team? Kids (including myself) just coming out of a training course in mainframe programming (COBOL- search wikipedia 
)
The seniors on the team? Well, not that senior- and used to work in “do now, pay monthly” projects, what in Italy is called “body rental”.
Simply: the people are dropped on the customer site, and the only link with their company is the paycheck, or when they are assigned to another customer or project.
The managers organizing the Information Technology for the customers were all trained in the 1960s-1970s, when technology was really expensive.
And it was used with a strict self-control on how many computing resources (including the number of lines printed) you were used.
We started being used to the first PC-based computing, were the worst that can happen is that you have to drink a coffee while something looooooooong has to be done by your computer.
Therefore… we wrote few lines. And then checked that everything was corrected. And again. And again…
As two years before at the University: the budget in technology was almost gone, well before it was due
And, moreover… it was the first large fixed-price project for my company.
1986, you say? Last century. Lost in time.
Wrong. Read again, and you will see that almost all the three elements in defining a budget were lost.
The only right element was the computation of the original budget- but in term of people, not everything else needed to carry out the project.
A project plan is subject to the mix of its team.
Cryptic? Well, if you read the small story about my first major planning experience, you will have something going in your head.
That something is probably… the difference in culture between the managers and the teams.
Do not get misled by the technology-oriented story: it applies to every generation.
If you read 2000 years old books, people complained about the impossible changes in work habits of younger people.
A project team composed of 5000 people is probably “team mix neutral”, as the large number allows to consider by average skills- but you will still need few “bureaucrats” (sometimes bureaucracy is positive!) to ensure that the team crowds work as an orchestra
The smaller the team, the higher the impact of team members on the real possibility of obtaining the expected outcomes of your project within the allocated budget.
But, unless you are operating with small teams that you have trained personally (or delegated their training to a trusted party), you cannot really control the mix.
Since 1990, few times I had the luxury of managing activities with people of my own choosing, available if, when, how, where I needed- and for as long as I needed.
If you cannot control the mix of the resources assigned to your team before you define the budget and then plan for the activities, you can define a “reference” budget and plan, that is based on “profiles”.
Actually: usually the budget for a project is defined with a level of confidence- i.e. how much trust you have in your own assumptions that generated the budget; the way you spready this “contingency” inside your budget is, well, up to you and what is customary in your buyer organization.
Again: do not make the mistake that I still see done by consultants- negotiating a budget based on how they work, and not how the customer works
But now that we are talking about budgeting and planning: remember, I am talking about projects.
If you need to define a budget for a service (e.g. something that you deliver after the project is completed), there are some other issues to consider- please refer to BusinessFitnessMagazine, and look for the issues on “knowledge retention”, “strategic outsourcing”, “business continuity governance”.
So, how is set a budget?
The budgets that I managed came in two varieties: the ones I received, and the ones that I obtained through negotiation.
Actually, now that I think about it… also those that I received where then subject to negotiation, as often I received a figure, sometimes with a team attached, often with some expected results- but I had to discover my way to understand the “framework” of the activities.
And this usually generated some negotiation to slowly become able to do something more meaningful that just try to solve a trouble after another.
Discussing the definition and negotiation of budgets outside the scope of a project and the results expected is outside the topic of this series- but more information about that subject will be published in the future.
For the time being, I will assume that a reference figure has been somehow defined.
Therefore, the planning is expected to be the means to an end- deliver the desired results within a certain framework, within the budget.
If the budget had been assigned with perfect knowledge, your plan would match the budget and deliver what requested by the due date.
But perfect knowledge on what is the cost of a project is usually not available before the budget is defined, the first step in planning should really be to see if the constraints match the budget.
As an example: if your project requires to deliver something within three months, where the time that the authorities have to authorize the project is six months, you have three main options:
- proceed: assume that somebody already knows that your project will be authorized
- edge: prepare a “flexible” plan, that considers what to do next, if an when the authorization is denied
- stall: prepare the plan, showing as a critical pre-requisite after the first few tasks the authorization
I did not consider the “theoretical” option: saying that the project cannot be done,.
Once the budget has been set apart, it would be politically unmanageable.
Bean counting is part of the budget definition and planning.
And also if it seems that most time-consuming part of planning, as you read above it is at the end of a lengthy mental process.
I underline mental process: because, sometimes, doing all of the above, if you have the right information, takes no more than hours or days.
Each industry and project-type has a history: and along with the history, a collection of information on how projects are structured in that specific industry.
Moreover, each organization has some “requirements”, that are not necessarily in writing, as the organization members are used to follow certain rules, that are passed from existing members to new members.
Beside, obviously, Information Technology projects, I also managed projects that delivered documents, or training, or helped assemble new physical objects or products, or events.
How do you deliver the planning for these different set of activities?
- you need to understand what are the typical constraints to a project in a specific industry
- you collect all the information I referred to above, including, if available, the team composition (or, at least, the typical profile of the people and resources to be used)
- you identify the key points within the activity (generally, “milestones”)
- divide the interval between two key points in activities, down to the level of detail where you can assign to people and resources the each activity
- identify if activities are interconnected, e.g. if activities from one point must be completed before other activities, seemingly unrelated, can be done
And then, once you have this theoretical plan… you can start adding all the constraints: if you have specific people, a fixed number of people, or amount of resources, you will need now to apply this constraints, and either modify the time, or add more people/resources (i.e. budget) to keep the same delivery time.
If needed, this is usually the point when I pick up the project charter, and talk with whoever is the “customer”, to discuss any issue that could after the final product of the project- or require to revise time/budget.
But if properly done, the planning activity has some interesting side-effects:
- you have better knowledge of both the project and the team, and of the real priorities/constraints
- you have a detailed plan that you can control (see in the next section, GMN2009: PROGRESS)
- it is much easier to discuss and negotiate changes when you asked approval for a plan listing activities linked to people, instead of generic figures
While the latter seems to be of interest only to external suppliers- it is not.
If you ask, say, 500k EUR for a project, and all you have to discuss is five milestones costing each 100k EUR: negotiation is like buying a used car or carpet.
If you ask the same amount, but linking the five milestones to specific activities, byproducts, etc, you can see that each reduction implies removing some activities.
Of course, if you are used to negotiate “wholesale”, then it takes time to build the new negotiating skills.
But if you want to link your planning to what you will be actually doing and viceversa, also negotiations should associate any quantitative information with quantitative information (talk about numbers to discuss numbers).
You can discuss about qualitative issues, but if you accept a qualitative change (e.g. have a higher frequency of communication on the progress of the building of the new bridge), then you have to consider the quantitative cost- who/ what/ where/ how much/ and so on.
All this brings to a last point about planning.
When you plan, do not forget to insert in the plan all the activities that are required by your “contract” (the project charter, or constraints of the model, call for tender, and so on), with their cost.
Also, do not forget to isolate the point where your activities could be affected by activities done by people outside your control- like the six months delay in authorization.
I found always fascinating when I was called as a project manager to take over a budget, to discover that often whoever negotiated the project accepted within the contract time-constraints, penalties, etc… but forgot to add all the necessary elements to keep under themselves the responsibility of the activities that could result in violating the rules.
Another typical mistake is forgetting to consider all the regulatory or organizational issues within the plan, such as: compulsory documentation, authorizations, approvals, certifications, security clearance of the personnel involved, quality-related documentation, training, knowledge transfer…
And this is the reason why, before accepting (or making the proposal for) a major project, I ask the authorization to do a feasibility study, via brainstorming.
The first time that I used this approach was for a decision support/controlling model, as the customer asked to build a model without giving any information on what they actually had or wanted- just a title.
It was in late 1980s, but I saw this approach followed also as recently as over the last couple of years.
To give you an example: the cost of answering to a major call for tender for Information Technology (that does not deliver anything physical) could easily go to 40-50k EUR, and require over one month to prepare.
I have been more than once paid to work on this phase, either as a reviewer or as a consultant.
But anytime that I was asked to do it as an investment- I turn it down.
Also, whenever I was supporting consulting and software companies, one of the first activities that I removed where the “free prototype” approach.
I usually instead build a fixed price feasibility project around one-two brainstorming sessions, with a pre-defined schedule to collect information before, and deliver the “scenarios” after the feasibility project.
The objection used to be: “you are asking us to pay you to tell us how much we are going to pay you”.
My reply? “What will be delivered can be used by you to better identify the right budget and requirements also with other suppliers, and % of its cost will be credited on the ensuing project, if assigned to us”.
This approach allows to collect the information that, in a company operating under one of the standard methodologies, would actually be delivered by the organization prior to the assignment of the project planning task.
But let’s assume that your plan is done and approved. Of course now it is time to execute it.
And, ignoring for the time being the potential troubles in coping with reality (that has the strange habit of not following your carefully laid out plans), maybe, if you built your plan following at least the guidelines given above, you can start by thinking how to chart your progress.
If you re-read this section along with GMN2009: MODELS and GMN2009: CHANGE, you can see that the main point is: if your planning is done properly, it can be used as a navigation chart also in a model.
NEXT
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.
Tags: brain, cost, dna, expert, feasibility, gmn2009, management, methodology, milestone, organization, planning, progress, proposal, scope