Friday, December 25, 2015

10 factors 3: stakeholders

3.    Stakeholders. Involve your stakeholders throughout the project. Get them involved in the analysis and planning, as well as execution. Gain their approval when needed and keep them informed when needed. The more you involve them, the greater their level of buy-in and the better you will manage their expectations.
'Stakeholders' are a various bunch. They range from the people with an actual stake in the project that they paid real money for, through those with a possible financial interest, to those who have no financial interest, but could be supporters or irritants.

For any interest group (and some interest groups will pretend that they are 'stakeholders' and should be given the attention that a proper stakeholder receives), as well as stakeholders identify their interest, their objectives, the strength of their interest and project risks that this might produce.

Then devise the separate management, communication and obstruction strategies for them...that's right 'obstruction' because some 'interest' groups are not interested in the project, not really. They are interested in the project not happening. For the project investor's interest, and with them kept fully informed, you might just have to obstruct them.

Saturday, December 5, 2015

2. Communicate visually

This alludes to a book by Woeppel about 'visual project management'. I haven't read the book so I cannot say if it is worthwhile, or just another PM gimmick.

Visual communication has had a boost in recent years with the preponderance of 'dashboards' as an attempt to communicate critical performance information to senior executives (or anyone, really). I use them myself, but one of the risks of dashboard reports is that they will be admired but not digested.

The idea of 'dashboards' was given its first outing, according to himself, by Charlie Kyd, who has an e-book on the topic. Edward Tufte's forum also deals with visual communication in regard to project management, wrestling with gantt charts, as though these are the be all and end all of PM information vehicles. Oddly, Tufte has some good ideas on this topic for medical charts. These could provide an approach for project management, conceptualising the project like a patient and bring a summation of past and current information to the chart.

The idea of visual communication: charts, influence diagrams, fishbone diagrams and the rest of the panoply of this genre is probably good, at a level. The idea of a project dashboard is good too, but one cannot escape the numbers. The two biggest numbers are: current expected (really truly expected) out-turn cost and current expected completion date. Nothing else matters.

Wednesday, November 25, 2015

10 factors 2: scope

2.    Scope. Define scope well. Get your sponsor approval for scope changes, making sure the sponsor understands any schedule, budget or other impact to the project.
In most projects what will be done can be ambiguous. The scope should remove that ambiguity; particularly by saying what will not be done that might be expected to be part of the project.

This can occur at interfaces with other activities (e.g. activities of suppliers, customers, the sponsor and other projects within the current program or portfolio).

Interfaces are a special problem because the boundary is where your project's expenditure should stop, or clarity created as to the process whereby the boundary can be crossed.

Change and configuration need to be pointedly managed to contain scope and ensure that the investment will produce the business results sought. Relax on your first change request from the sponsor's bright eyed young star, and you may have changed from the high road to the low road. You will wear it and not him or her.

Rules and processes enforced by the PM for change acceptance and budget and delivery effect need  to be set. Additionally the effect on overall outturn performance and high value requirements needs to be advised to the sponsor: does he want  THIS project, or some other project that will do some other thing?

Thursday, November 5, 2015

1. Avoid multi-tasking

Yes and no.

Sure, don't try to work on a number of independent tasks at the one time, you'll end up with inefficiencies of time and effort for all, resulting in poorer performance that obtained by concentrating on a task until it comes to a stable stage (when you can leave it with minimal inefficiency upon return to it).

However, a PM, like any manager, hops from issue to crisis to ceremony ALLTHETIME. That's what management is.

The 'secret' is to organise this torrent of calls on your time with an end in view; not just the project as a whole, but on current delivery chains: actions that must be taken and completed to maintain the tempo of the project.

Wednesday, November 4, 2015

Value for money

Particularly on government project, I often hear the phrase 'value for money'. From time to time I've asked how it is measured. Often I get long vague replies, revealing that the answer from that person is 'I don't know'.

I think that there are three approaches to assessing value for money:

1. market comparison: for a similar service or product, what would a commercial organisation expect the market to offer for the service or product? Market comparison was something I used in the heady days of 'private financing' of public infrastructure.

2. opportunity cost-benefit: before I spend $n to achieve a certain result (service, product or capability), what other benefits could I obtain for spending that amount on something else. In some cases the answer would be a market comparison type answer, but it also would help the spender assess if the plan represented a good use of money.

3. capability for cost: somewhat like a QFD assessment, what capability am I getting for the cost? Particularly, am I paying for capability that I do not need and therefore paying too much? What then should I be paying for the capability I want? The question is answered by item 1 or 2 above.

Tuesday, October 27, 2015

Percent complete

We've all been there: seen a report on project progress that tells that an activity, or even a whole project is n% complete. The use of the '%' of course, leds an air of calculation to the fable being peddled.

The only time I could think a percent complete would work is for some linear unit activity such as bricklaying. One could count the bricks, then work out the percent complete of the activity. But this all falls down as soon as the activity includes non-bricklaying work: cleaning the site afterwards, removing equipment, even scaffolding (now, that should be a separate activity). The estimate of progress becomes a bit of voodoo.

In a report of a major capital program that I prepared quarterly I used a different system. The two items we tracked were out-turn cost (end of project, all done and in use) and completion date (same: all done, in use). For each project in this multi $b program we tracked original approved date and cost, current approved date and cost and forecast completion date and cost.

This put each project team on the spot with clearly objective and checkable information. They were committed data!

It was reminiscent of an approach that I came across many years ago using Timeline for DOS project scheduling software.
They used a '0-100%' measure. If an activity was not finished it was recorded as not started. It was recorded as complete only when it was complete. Again. Clear rules, real information. Of course, to be useful the activites had to be quite short, and a real view of the whole project progress could still only come from something as rigorous as an earned value system.

Interesting story about Timeline. I had it at home on my old Amstrad 386 machine, and had just started working on a factory project for my firm. I don't know how the partners calculated their costs, but I put the project schedule into Timeline with all known labour costs. I took the report on project cost projection to the partner in charge who was more than surprised at the number I calculated...I don't think they had ever done that before!

Sunday, October 25, 2015

10 factors 1: requirements

1.    Requirements. Make sure that your customer defines their requirements in depth. You need to know exactly what must be delivered. Be specific, write them formally, and get them approved. This document will become one of the baselines upon which to measure your success.

There's far more to it than this. Your client/customer will have a strategic object for its project. It might not be clearly stated or even understood, but every project has to advance the organisation's mission, or it is squandering its resources.

So, first: how does this project advance the mission? What strategic role will it fill?

Then, requirements. But 'requirements' is not just a list of things. To fulfil its objective a project must produce a level of performance, and have trade-off rules because you will never have enough money to do everything you want.

When you are refining the requirements and trade-offs, also define acceptance criteria for the requirements. Be clear hear because these will drive cost or performance. Acceptance criteria too high: performance required too restrictive, then costs could sky rocket. Performance set too broadly and performance might not be adequate. Either way you have to know when you're done and what 'done' looks like (to borrow a phrase that Glen Alleman uses).

Get those set first, then you can talk about 'requirements' and start bringing resources to bear.

But all this needs to be done with people: the people who will use the project's output: sponsor/s, customer/s, users and other 'stakeholders' or interested groups (regulators?).

Friday, October 23, 2015

Project method

Project management 'methodologies' come and go; or more to the point, come and stay, competing for our attention.

In some places I use the Prince 2 method: which can become excessively cumbersome if the PM doesn't 'nimble-ise' it.

Some people regard PMBOK as a method. It is not. Its a list, a conspectus of project management, not always particularly helpful for the practicing manager.

I like the Project Success Method (not the snappiest name), but it nicely combines good theory, good practice and good teaming, all woven into a practical doable and very scalable approach to projects.

There are four basic components to it, using interactive team processes (reminiscent in my practice of using Value Management type workshops throughout the project, from commencement to progress reviews). The four components (1-4) then lead to the activating processes (5-7).
  1. Develop a project charter
  2. Define the work (using a work breakdown of whatever detail is useful)
  3. Set activity relationships in a precedence network, setting the critical path/s
  4. Prepare a schedule (time the activities on the basis of minimum cost per activity)
  5. Compress activities on the critical path on the basis of cost of compression vs money saved/expenditure avoided. Keep cycling through this until all beneficial compression has occurred. This forms the baseline schedule.
  6. Update the schedule on the basis of 'expected to complete' dates.
  7. Review the network, re calculate the critical path, check for end date against baseline end date, and compress on the critical path again if necessary. Or, re-work the network to shift the critical path.
My own contribution:

Where possible include risk probabilities and use reference class experience in estimates to give an (agreed) 85% probability on meeting the estimate (the particular level of probability depends on the circumstances, of course).

This can be elaborated up or down depending on the size of the project, the management overhead capacity and sophistication of analysis available (earned value).

Monday, October 5, 2015

5 surprises

In his Projects in Less Time blog Mark Woeppel has a useful post on the "5 Surprising Habits of Successful Project Managers".

Let's discuss.

The surprising 5 are:
  1. They avoid multi-tasking
  2. They communicate visually
  3. They collaborate intentionally
  4. They build a one team one goal approach
  5. They control the work in progress.
I'll discuss over the coming weeks.

Sunday, September 27, 2015


Many PMs working in the building industry would have come across the name "Le Corbusier", a notable French architect of decades past. Many of those same PMs, of course, would have a degree in architecture.

Now, to lift the lid on Corb, an article in Quadrant. Much like E Michael Jones' lifting of the lid on architectural modernism.

Good for him, now let's get on with making buildings for people, not people-resistant ideas.

Friday, September 25, 2015

10 project factors

I recently received an e-mail from one of the project management services that has my address. It offered 10 factors for project success. They are:

1.    Requirements. Make sure that your customer defines their requirements in depth. You need to know exactly what must be delivered. Be specific, write them formally, and get them approved. This document will become one of the baselines upon which to measure your success.
2.    Scope. Define scope well. Get your sponsor approval for scope changes, making sure the sponsor understands any schedule, budget or other impact to the project.
3.    Stakeholders. Involve your stakeholders throughout the project. Get them involved in the analysis and planning, as well as execution. Gain their approval when needed and keep them informed when needed. The more you involve them, the greater their level of buy-in and the better you will manage their expectations.
4.    Duration. Keep your delivery timeframes short and realistic. It is easier to be successful if your deadlines are shorter rather than longer. Split large projects into "mini-projects" if possible. Keep each mini-project to less than six months if possible. This keeps everyone motivated and focused.
5.    Communication. Make sure you keep everyone informed by providing the right information at the right time. Produce status reports and run regular team meetings.
6.    Quality. Understand the expectations of your customer in terms of quality and put a plan in place to meet their expectations.
7.    Issues. Jump on issues as soon as they are identified. Prioritize and resolve them before they impact on your project. Take pride in keeping issues to a minimum.
8.    Risks. Risk management is a great proactive way to solve potential problems before they occur. Identify risks early in the project and continue to manage risks throughout the project.
9.    Deliverables. As each deliverable is complete, hand it formally over to your customer. Ask them to verify acceptance to make sure it meets their expectations. Only then can you consider each deliverable as 100% complete.
10. Your team. Be a great people manager. Show them the project vision and how they can make it happen. Motivate them. Trust and believe in them. Make them feel valued. They will work wonders.
Over the coming months I will discuss each factor and seek to put in into a more professional context.

Sunday, September 20, 2015

Guiding Principles 10: Reuse

When possible, use existing processes and tools before creating or buying new ones.

A while ago I posted against the reflex reliance on ‘best practice’ to advance a project. Best practice in an oil drilling project might not be best practice in building a foundry or a robotic assembly line...or it might!

In projects the domain and context of the project is all important under the guiding judgement of the project team. So it depends on what type of project.

However, that said, the idea that does the rounds in pop management circles is to ‘fail often and fail early’. That might be fine if a minor process inefficiency that is easily corrected is the result, or in a paperwork activity that entails more hours than it should. It is not OK, as Glen Alleman points out, if you are putting a Rover on Mars, ‘cause there is no second shot. It is a right first time game.

So a project team finds, or knows, what works best. Innovate for sure, but do so against the backdrop of project needs and circumstances. Innovate to improve, to fine tune a working process, but don’t blue sky when the risk is project value that you know will be produced by known techniques.

Useful post by Glen on this.

Saturday, August 29, 2015

The job

I recently reread a number of articles on management as I prepared for an interview for a role in a senior exec team of a med sized business ($200m annual revenue). The job advert talked about project skills, which I think I have in spades, but the panel obviously saw better elsewhere.

Nevertheless the articles I looked at also have a bearing on the management of projects. I commend them to you.

They are all by Henry Minzberg: Rounding Out the Manager's Job (Sloan Mgt Rev Fall 94); The Five Minds of a Manager (Havard Business Review Nov 2003) and The Role of the CEO, which I think was a Harvard publication, but I found it on DesignIntelligence Update.

I'm familiar with the first two, as I give them to the managers who report to me (and staff who are on a management pathway) to read. They both open up the world of management with more reality than most texts do.

One of the ideas that I like in Minzberg is that he talks about the role as being an integrating role; a role that brings lots of active plays to rolling conclusions. Much like a PM; however most of what I read about PM breaks the role into analytical approaches to PM 'tools' and techniques, but rarely integrates in into a flow of information, activity and people's commitment to produce a performance outcome.

Thursday, August 20, 2015

Guiding Principles 9: Cost efficiency

Calibrate resource use and project management costs with project needs and expected returns.

Clearly essential to the sustainability of the project; but too easy to forget when an executive is going for broke to show that he or she has the goods.

If costs and their effect are not managed, the executive responsible could end up looking for other work.

Notice I’m not talking about the PM here, but the executive responsible. I take it the PM is keeping track of every cost account in the project and doing some sort of ‘earned value’ management, even if only informally.

An informal EV process won’t give reliable information, but with a skilled PM it will enable some objectivity in assessing progress and delivery against the expected value that will be produced; and in project delivery, business value is the only game in town.

Tuesday, August 18, 2015

PM training

How to train non-project staff in project management?

I have access to short courses sponsored by my employer that could be used, but from what I've seen of them they are what I call 'lock-step' or recipe courses. A collection of 'do this then that' courses rather than invitations to think through projects.

One course that I did like, also a short course, is the one at Stanford University. Looks good, but pricey!

I would steer away from courses aimed at a qualification: Prince2 and PMBoK (so called) as they train to the qualification; again, not for thinking about projects.


Of the longer courses I think I'd lead towards Adelaide Universities' masters degree. It seems to be pitched at an appropriate conceptual level, but that's for longer courses.

What do I want in a course?

  1. The business context of projects: the financial and competitive environment and how projects arise and are handled in organisations.
  2. Projects as systems that respond over time to their own evolution effecting resources, information, capability (both the input capability and the performance capability sought).
  3. Structure of projects: getting to details of the WBS as the central driver, and working back through dependency relationships. This would touch on the low level tools of scheduling, tracking (earned value), delivery methodologies and handling risk. I'd be loath to handle 'risk' as a separate category as risk should be incorporated in the project plan through offsetting activities, and scheduling adjusted for delay risk on a probabilistic basis, or at least using Goldratt's buffer system.

Thursday, August 13, 2015

Project principles

I like the approach that Adam on Projects takes to project management. I've placed his blog in my list on the RHS of my blogsite.

He has five principles to guide project work. I might discuss them at some time.

His diagrammatic representation of them is below.

Tuesday, August 4, 2015

What is PM?

From time to time I put my mind to the characterisation of project management. What, I ask myself, is it? This usually occurs when I consider approaches to training staff to think about projects, rather than simply learn a few techniques absent a theoretical structure that will orient them in the practice.

Is a project a choice reduction machine, a transformation machine, or as Koskela puts it a means of managing flow. Flow I like, as long as the flow includes information, its creation and management.

My starting point is the people who form the project: at the start they constitute a 'community of intent'. What's special about that, you ask. The special thing is that it is free agents coming together form different perspectives to contribute to an outcome. All management is about this, I suppose, but in project land, the community is for action that will take an organisation from a dissonant  relationship with its business environment to one in equilibrium. The dissonance might be a problem, a deficiency or an opportunity. The dissonance provides impetus for action by bringing the business to a a more stable relationship to its environment that produces the sought benefits.

Equilibrium doesn't mean smooth sailing, but that a point of dissonance has been dealt with: a new product, capability or investment available that deals with an opportunity or deficiency in the previous relationship with the environment.

Not yet a theory, of course, but that's how I think about it. Without a theory we have merely a collection of techniques with no home. We need the home.

BTW, list of Koskela's papers.

Saturday, August 1, 2015

Something lost...something found

The Pretenders' song Hymn to Her was mentioned at a recent Economic Society of Australia symposium that I attended on Cost-Benefit Analysis. It was cited as a quintessential economics song: opportunity cost sprang to mind. But to my mind it is more of a PM song (well, its even more than that: one of the great ballads of the 80s): "something is lost--something is found" in day out for busy PMs!

Old time

Sorting out my library recently I bumped into a little known classic in project management: Modern Project Management by Claude Burrill and Leon Ellsworth.

Flipping through the pages I was a little surprised to see that the sound principles that this pair laid down over 35 years ago still have made little headway in project management.

For example, they wrote about probabilistic risk estimating; most people are naive about this and plan their projects absent of any realistic incorporation of either schedule risk or budget risk. So, of course, too many project slide over one or both to the surprise of the project team and the anguish of the investor.

The corollary of this is that most people embark on a project with a risk management 'ceremony'. They have a chat about risks (no fault mode analysis, no dependency risk analysis based on the project WBS, if there is one) involving making a cute matrix of coloured cells that pretend to represent risk appraisal. Of course, it does not.

For your risk management edification, a useful post on an analytic approach that can provide useful case study input to considering risk.

Tuesday, July 28, 2015

Just don't do it

Don't do what?

Why, use PowerPoint of course.

This evening I was at a formal inauguration of an academic scholarship in honour of a deceased professor of the school (professor means head of department, not just lecturer, as in the USA).

We had PowerPoint for some images related to him and his work...about three I think. During a speech the computer decided time was up and switched itself off. The image projectors declared that there was 'no signal' and joined the sleep circus.

The technical man ran down, woke up the computer, that woke up the projectors, and of course, he had to restart PowerPoint in edit mode, switch to show mode and flick through to the right slide. Pathetic.

Lessons  (or 'learnings', as we like to say today)?
  1. turn off the power saving features of computers before the presentation
  2. make sure the projectors don't go to sleep
  3. save the  PowerPoint in 'show' mode so you don't look like a dork when you start or re-start it, frigging around with the mouse to turn to a slide show (F5 does it better, by the way)
  4. convert the PowerPoint to a video (Quicktime?) and just run it in a loop.
This was at a university with 'technology' in its name...unbelievable!

Monday, July 20, 2015

Guiding Principles 8: Time management

Encourage project managers (PMs) to value time—both stakeholders’ and their own—when making project execution decisions and managing meetings.

Worth mentioning, but I’ve not come across any competent project manager who doesn’t move at an intense pace: tightly run meetings, concise communications, and clear advice.

This topic is often discussed as 'time management', but do we manage time? No. Time passes. What we manage is delivery or project performance (distinct from technical performance, or how the project object does its job).

Good delivery management comes from good information management. And if there is a primary element of project management, it is managing the flow of information to keep abreast of the state of the project, its dependencies and interfaces.

The communication system that moves information through the project team and documents the movement of information makes time management efficient and effective. Without it information is unreliable and its value to the project drops, imperiling the project outturn value.

Wednesday, June 24, 2015

Now, what is a PMO for?

Where I work we have a PMO; its not called that, which is good, because it's not a very good PMO.

Why not very good?

Because it is an information one way street. We all provide data on our project timing, but never see a consolidated report to enable us to link up projects, reduce redundant deployment of resources and people (note, resources are not people, and vice versa), and generally get more efficient. But it doesn't happen and currently we have three projects doing overlapping data remediation actions using the same big database!

In the old days in my firm we had a more organised system than currently for keeping the execs on top of what was happening. A quarterly report was done in a standard but awkward format (some genius has crafted tables within tables in Word! Not good; and there was no calculation on any numerical or data data) and submitted to an exec meeting.

The report was not as useful as it could be but, at least the executive committee could compare and line up projects with each other, which they did in part, but not thoroughly due to they didn't fully understand any of the projects reported!

A PMO should make connections, bring people together, and overall save money while improving project portfolio returns, otherwise it is just a template shop.

Saturday, June 20, 2015

Guiding Principles 7: Risk management

Enable informed tradeoffs between project and portfolio risks and potential rewards.

Risk management: Enable informed tradeoffs between project and portfolio risks and potential rewards.

It’s right to couple risk and reward. Once goes with the other. But let’s not get led astray by the financial market’s conceptualisation of risk-reward. Across an investment portfolio this works, but the project risk environment is not like an investment portfolio. You can’t sell stock in part of the project and buy a bit of another project to balance the risk being faced. That would just under-resource the first project and head it to failure.

Risks in a project are at the heart of project management. This extends from risks in the project environment (what we normally call risks) to risks created by the project’s organisation. K has a useful post on internal risks that teases out this concept.

Managing risk is not done by dreaming up a list of risk around the table, ‘weighting’ them  -- usually without statistical reference -- and placing them in a matrix. That’s not risk management, that’s a ceremony; but organisations do love their ceremonies, thinking that they achieve something over here in the real world.

The management of risk has to show up on the schedule and budget, and be aligned with the dependencies of WBS elements and have calibrated probabilities attached. This helps structure the project to avoid risk, but also to deal with it when it occurs, even if it is by insurance; and insurance is the last refuge of the scoundrel project director in many contexts.

Wednesday, May 20, 2015

Guiding Principles 6: Proactivity

Take a proactive approach to identifying and resolving project challenges.

By ‘proactive’ I suppose they mean ‘active’ (I just quibble with words here, but ‘pro-active’ is such junk English).

The project team has to actively identify and resolve project challenges. That’s their job. Now, what could distract them from their job?

It is the C-suite that has the answers to this: remove obstructions from the team’s work in doing this, and get rid of the fake ‘challenges’ that could impair the project.

Fake challenges? I mean intentional under-resourcing, creating problems at the interfaces, applying corporate rules to procurement that might not serve the project’s interests, creating an environment that punishes honest reporting of progress or lack there of. Then failing to take advice on solutions that the project team can see.

Tuesday, May 19, 2015

Using word like a typewriter.

Part of using Word to communicate is to give a document clarity of layout. Some of the message is thus sent by design.

I had a document from one of my team leaders that needed some content edits, and it was quicker for me to get into it and do them myself. Nothing dramatic, so no real coaching opportunity in it.

The document opened I couldn't quite see how it was constructed so I turned on markings--and what a mess!

Instead of using Word's tools like tabs, tables and cell positioning, paragraph layout, my colleage had used the spacebar...for everything. Move one piece of text and the whole line is thrown out, move another and the vertical order is wreaked.

A real step back in efficiency.

Thursday, May 14, 2015

Check the e-mail

How many times have you received an e-mail, read it, then acted, only to find that the real message was in the 'trail' of e-mails below the one you read; below the 'fold' in web design parlance.

I usually browse through the trail to see if there's anything there for me, but last week, I didn't. The request seemed to be self-explanatory and self-contained. The trail below it also seemed to be giving various positions, so the author I read had assumed that a reader would work out from the complex trail what they were asked to do.

Not so, too many choices, too many assumptions would have to be made.

To convert this melange to communication, if you must send an e-mail trail, copy, paste and edit to make sure you send the message you want action on. Projects are too complex to think that a reader can work out what you mean from a long trail of e-mails from different authors full of discussion, fact, and inquiry.

Saturday, May 9, 2015


Governance is a special case of leadership or management.

Just like leadership it runs on information; but this time it features reporting and decision making structures that cover all aspects of a project or organisation, and not restricted to core delivery.

What do I mean?

Project governance is centrally to do with decision making that affects the delivery of the project and its relationship to corporate (owner or sponsor) priorities and mission.

The basic question of project governance is "is this project going to deliver the value that will advance the corporate mission, compared to other current or forthcoming opportunities.

In the answer to this question the risk of throwing good money after bad has to be confronted boldly. Be prepared to end a project that will not produce what an alternative use of $ will.

Tuesday, May 5, 2015

Fresh new role for the PMO

A project management office is usually looked to to provide a consistent project infrastructure within an organisation. It also connects the organisation's executive to project performance information in a reporting system.

It can, should, indeed, must be more: to build project capability and bring benefits from projects.

My project managers have meetings with our version of a PMO each month, where they dutifully talk about activity completed and delayed, and risks that have emerged. No work is done to connect our projects to any other projects in an organisation full of interrelated action to achieve a grand mission. There are no forums it sponsors to bring people together, no practice development discussions to share approaches or ideas. Nothing except a regressive check on what's happened.

I think you can get the picture. If a PMO is not building capability, bringing people together to develop expertise and find project relationships, then its not contributing to the value mission of the organisation. Change it, or get rid of it.

Thursday, April 23, 2015

What are buildings for?

Most of my project work has had something to do with buildings, or groups of buildings (my wider property portfolio work).

One of my 'lecturers' in architecture was Micha Bandini, who asked the memorable question 'what is architecture'? We all fluffed around with answers. She tried to help us by asking if a chair (a 'designed thing') was 'architecture'. We thought not, but I don't think anyone explained why. I don't even recall where the discussion got to, but given MB's arty-philosphy credentials, meaning that people and society figured little in her thinking as far as I could tell, I expect that any definition excluded what buildings are really for. I say 'buildings' because that's what they are. 'Architecture' is a practice, not a thing. It doesn't come in pieces, like chocolate.

I saw a good response to the question in the blog Life of an Architect:
The title of the post reminds me of a misunderstanding of architects' work that abounds in industry and commerce: that we 'draw up' buildings, as though someone else formulates the program, designs and develops it, considers the practicalities, brings the multiple professional disciplines to realise an effective 'socially significant shelter' as well as creates the spaces and enclosing form for meaningful human activity.

One page

Since the publication of the One-page Project Manager, there has been a bit of Internet effort to do the job. The idea of a 'dashboard' is similar, and I use such myself, but I don't know if the 'one-page' nut has been cracked yet.
Based on articles by Edward Tufte, I've had a go:

Monday, April 20, 2015

Guiding Prinicples 5: Stakeholder partnership

Establish personal connections with stakeholders based on leadership, trust, and credibility.

Relationships deliver projects, as they deliver anything in business. You have to be able to understand the motives and objectives of the people who are interested in the project to navigate the landscape they jointly create for the PM. The connections have to be personal and open: but not crazily open, cannily open is better as you feel you way about the different depths of trust and commitment throughout the project constellation.

I can understand how trust and credibility are at the table in this, but puzzled about ‘leadership’.

Leadership these days is a popular shibboleth for ‘I’m talking serious business, folks’. But I’m neither sure what it means in this context, or how it is applicable.

Maybe we operationalise this idea by directing communications and information flow, advice and insight, even views of the project ‘climate’ relevantly through the members of the project constellation (the ‘stakeholder’ group).

Sunday, April 12, 2015

Someone else's project

Not my project, but thoughts about another's project: Frank Gehry's brown paper bag at Ultimo in Sydney.

I'm not sure if I'm a 'fan' of Gehry's or not. Probably not, because I'd doubt that I'd be a 'fan' of any architect.

The building is impressive in some ways, with some of the emptiness of its impressiveness touched by Philip Drew in this review.

Just to note, I read Philip Drew's book Leaves of Iron; an essay on Glen Murcat's work. There were some nice touches in the book with its mentions of people, places and buildings that I knew well or had worked with, but I thought the writing pretentious and over-done. Drew's essay on Gehry much better, in my estimation.

Thursday, April 2, 2015

Not too much, now.

A little while ago I wrote about documenting even the small jobs. A similar rubric is not to over-document.

I recently asked a team to prepare a project plan for a major piece of analysis on the performance of a $350m program that I direct. They diligently used our project planning template, but, alas, it was too much for the scope of the project and attracted unhelpful questions. Good questions, but ones that mislocated the intent of the project.

This was nothing dramatic, but it reminded me that the project plan has to be right-sized for the project scope and probably, if you want to apply a metric, for the dollars likely to be at risk in the project.

Saturday, March 28, 2015

Document Everything

In investigative work, of which I've been involved in, there's the well known rule of ABC; I've extended it to 'ABCDE'; less snappy but more representative of the work:
  • Assume nothing
  • Believe no one
  • Check everything
  • Document
  • Evidence.
In a project context, we can make that 'document everything.

I sat down with a 'not-senior-not-junior' member of my project team last week to discuss her work. I'd been puzzled over the seeming order in which she was doing it;  with her team leader being away it was time to make inquiries.

I found a disaster unfolding before me.

Her team leader (the away one) had been quite clear on the mission and was seemingly executing it well. It was relatively small, self-contained and low risk, so I left it to her.

In the transfer of information to the 2IC team leader something had gotten lost and the tree being barked up was in the wrong forest!


A brief project plan, or statement of brief would have clarified everyone's perception, so I'm going to knock together a template for just such a thing. It makes good procedural discipline as well, so that a pattern of activity is instilled in the team when undertaking a contributory task, to ensure they know how it advances the overall mission, and so they can see how it achieves what it needs to.

Friday, March 20, 2015

Guiding Principles 4: Shared accountability

Create commitment to a shared vision of project outcomes.

Often this advice is directed to the project team; and yes, ‘commitment to a shared vision’ is important to the project team. It is important that the  PM keeps his/her eye on this and makes sure it produces the results needed.

Where the shared accountability is required is at the company executive level. It is here that projects can be subject to shifting commitments, factional jealousies and even sabotage. If a senior exec is not pulling projects into order and ensuring they are effectively supported at the executive level, even by executives responsible for dependencies and who have an interface to the project, the project has slipped of the road to success.

Thursday, March 19, 2015

To Powerpoint or not...

Some observers have claimed that one of the contributing factors in the space shuttle Challenger disaster was the use of Power Point to communicate complex engineering considerations to decision makers.

It didn't work it is suggested.

This can be attributed, at least in part, to the problem of the medium, reminiscent of Marshall McLuhan's quip "the medium is the message". Powerpoint constrains, guides and
'encultures' communication to the minimal 'points' that can be crammed into a slide. It doesn't suit the complexities of argument and judgement, but only the conclusion, or the way stations of thinking; not the reasoning itself. It lead, in the case cited, to the fatally wrong decision.

There are plenty of good ways to use Powerpoint, and that's to provide graphic information: relevant images, graphs, and so on. But only in context, and not just because you can. So I was pleased to read this in the Fin Review the other day:

Friday, February 20, 2015

Guiding Principles 3: Enterprise perspective

Consider the impact of project decisions on enterprise value, not just project or PMO objectives.

If the PMO has separate objectives to the ‘project’ or the enterprise value, the PMO is out of control.

A good PMO is a facilitating mechanism to give order and uniformity of process and language to projects, assist in coordination of resourcing, sometimes including financial resources (cash flow, finance needs), communicate overall project commitments to the executive and identify emerging deviations from plan. These need to be first taken up with the PM (or even he/she is not ‘empowered.) and jointly taken to the project executive group (the governing body for the PMO).

The PM has to balance the investment-value couple: the outturn value has to  be over the investment hurdle: will the return be enough? Almost no other question applies.

Sunday, January 25, 2015

Guiding Principles 2: Judgment

Empower project staff to make decisions about methodology application and trade-offs between scope, schedule, and budget when necessary.

Rather than ‘empower’ staff, a decision-making process needs to be created and everyone told how to use it. Staff decision making has to be circumscribed by the staff member’s circle of responsibility, down with in project constraints and objectives and communicated to the relevant part of the project structure. Where business value or performance is affected, the project manager must know and a proper change process used.

If ‘project staff’ in general were to make the project-critical decisions that the Executive Board’s advice suggests, you cease to have project management and have project mayhem instead.

Monday, January 5, 2015

The practical day

Most talk about management, including project management, is at a level of generality that might frustrate some readers.

Here I seek to be practical in one small area: how do I organise my day and keep track of information, commitments and the multiple projects that I direct.

Unfortunately my employer gives us Microsoft Outlook as our group organising and communicating tool; we've recently started using Yammer and have HP TRIM for document management.

Yammer so far is a distraction; it has been useful for internal discussions across the organisation (which has offices across our state), but I'm not sure about the more structured communication needed for projects.

In one of my projects we are going to use it for the development of one deliverable, but that's a single topic activity, not trying to cover a multi-dimensional project with what is essentially a one dimensional tool, even with its 'groups' '@' tags, and document sharing, etc.

Thus, its a distraction. Yet another interface to have to manage. And that brings me to my daily organising.

The biggest efficiency in e-mail came to me when I made a rule to place all messages copied to me in a 'cc' folder. I check it a couple of times a week. From time to time people tell me they've 'cc-d' me with a matter that they need me to directly to respond to. I explain that if they want to get to me, address me directly, 'cc' tells me that its just for my reference, not action.

We add a prefix to our e-mail messages: Urgent, Action, Information. A drop down to choose these and project titles would be a helpful addition, as would chaining of conversations, as per G-mail.

I use topic folders as well, but tend to leave my in-box pretty full. If an e-mail relates to something that will absorb time, I move it to the calendar and give it a duration to do the work. E-mails that I want to attend to but not sure of the time commitment, I place a flag on. They then show up below by calendar as a list of follow-ups. I have search folders set up for un-read e-mails and flagged emails.

That seems to be pretty successful for my work pattern. I check my e-mails in the morning, but not first thing, late morning, after lunch and late afternoon. I tell people that e-mails are not for urgent matters. Use the phone or text me!

The calendar contains everything that has either a duration or date related to it. I manage this quite actively, moving time commitments around frequently: not meetings, of course, they are usually fixed.

I use the 'all-day' setting to keep track of staff absences and special commitments, and share my calendar with my entire staff ('team' as we like to say these days, as though its a game!)

I drag all the required documents into the meeting item. As Outlook copies documents into an appointment, there is a risk that we end up with multiple copies, even in one's own client. Definitely not good. Where I can I have the document's TRIM link instead.

After a meeting, I sort out tasks I need to do and allocate time for them in separate calendar entries. I also add notes directly into the meeting item, and add any documents distributed during the meeting (if necessary I scan them. The scanner e-mails them to me, then I drag the e-mail to the meeting item).

The Outlook 'tasks' function is not so useful for me because it doesn't provide for task lead times or durations. Nor does it allow tasks to be grouped (afaik) or linked in dependency relationships or sequences. This is a killer! There are third party apps that will do this job, but I'm not able to install them at work. The tasks time information is also in a separate interface to the calendar, so its yet another place to keep track of, so not efficient.

My ideal would be to have everything in one interface, but I've got to manage two: Outlook and TRIM; however they can connect.

It is impossible to link documents on the server to Outlook. They have to be copied into the particular Outlook item, and then are 'buried' in that item and not otherwise accessible or searchable. However, with TRIM one can e-mail the 'TRIM link', to facilitate communication. This keeps documents in a version controlled environment which is great.

The one function I'd like in TRIM is to be able to keep private notes on documents. Notes are public to all users, so one would not write 'notes to self'. They have to be kept in another place.

For documents that are important to my work I e-mail the TRIM link to myself and keep a consolidated folder for all TRIM links, and copy link e-mails to topic folders as well; again, copies and not pointers (Zoot is great for using pointers, as is Infoqube, and old Ecco...).

For random notes I use OneNote and link the entry to Outlook.

What I miss is a project orientated interface where I can easily keep a running log, manage project activities, attach documents to WBS elements, and tag for other project dimensions. For example in construction projects, the obvious dimensions are: location, building/structure element, material, discipline (e.g. mechanical, electrical, structural, architectural). Such an interface should also simplify linking all project records to the WBS structure; this would include meeting minutes, memos, informal e-mails, status notes, links to 'issues' and 'risks', budget and expenditure, etc.

My production meetings are short, sharp and stick to the agenda. I discourage 'AOB' (any other business) unless its pressing for the project's current position.

Items in meetings are numbered for the meeting series, meeting number (d-m-y), item number to create a unique and easily tracked reference.

Thus, for a sub-grade coordination meeting on 3 March 2014, first item: SGC-3-3-14-1 (I don't like leading zeros, unless the computer needs them for sorting). On a large project you need a lexicon for abbreviations and special terms. We would use the TRIM location for the project for that document, and place it in a relevant sub-folder.

I'm experimenting with Evernote, which is highly good! But, its yet another interface, so I'm reluctant, OneNote cloud service might work if it will link to my virtualised OneNote client.

Lots of Activity
As I am responsible for a number of projects, again, absent a proper project management interface, I am stuck with using Excel (how humiliating!) with a row for a project on a master sheet, and a sheet for each project. I maintain this manually which keeps me deep in each project. An automatic system would lead to complacency, I think and not keep them actively in mind. I use formulas to link the project sheet information to the summary sheet.

Friday, January 2, 2015


The concept of leadership attracts a lot of attention. Hard, though to shake off its 'heroic' dimensions.

The leader as corporate, or project, hero remains as strong as ever, particularly in recent times as popular management writing has shifted to managing culture...the 'soft' side of organisations and the NBT (next big thing) for consultants to take to market.

But, let's lift the lid on leadership.

First, one underlying objectionable concept.

Leadership fits well into a paternalistic conceptualisation of organisations. It either assumes that employees are unmotivated, unresponsive dullards, or that they need to be organised like children. Leadership seems to presume non-adult behaviour, in its worst manifestations.

The positive side of this is that the manager (I follow Mintzberg in this term) provides a 'holding' structure for staff (have a look at Heifetz on this), particularly when the environment presents challenges such as changing demands.

Second, the basic operational need in organisations, and projects too.

Managing information.

The 'leader's' job is to make sure that information flows to where it is needed. People will then lead themselves in terms of their role. If they don't you have the wrong people: professionals bring with them knowledge and understanding, initiative and, one hopes, self-awareness. Find such people if you don't have them.

Alongside managing information is creating it. Decisions create information. Decisions need to be informed, so the decision-maker needs to listen to those who can inform the decision. Then, make and communicate the decision, and leave space for your professionals to let you know the implications and dependencies attendant upon the change.

Third, let's not forget power.

The manager has power in an organisation: he/she controls resources, has 'clout' to talk to others that staff might not have and in many cases can hire and fire. The manager also allocates work and directs activity. If they are smart they do this collaboratively (see the first point, above). In most work settings, the power is underpinned by law, both statute and contract! Just look at the power the NSW Work Health and Safety Act thinks a manager (an 'officer') has!