Sunday, June 28, 2020

Project Software: what does it need to be?

Microsoft project is not project management software. It is schedule and resource software. Same for Primavera and all the other scheduling packages.

Safran Risk is not project management software; although a very important package for understanding the risk implications of schedule.

What is project management software?

This is software that manages all the information flows, project configuration, and documentation with respect to delivery, investment and performance (the real world version of time, cost and quality).

Every piece of information in a project has a number of dimensions. I'll use a big campus development as an example. Think of a new air terminal.

It has numerous buildings, areas of paving, electronic, lighting, communication and sensor systems. It accommodates land side and air side vehicular traffic. It accommodates the flow of people, cargo, supplies and traffic.

The dimensions of each piece of information about the project are:

Location: in three dimensions. A latitude and longitude, and an altitude. These can be expressed in site and building zones (taking a ground plan perspective), and floor levels vertically. At the micro level, rooms are the location. Then there are groups of rooms and types of rooms. Groups are contiguous, types are logical (and could be discontiguous). Rooms are collected into buildings, on floors and in zones of buildings. Buildings are within precincts. Civil works have zones and are also in precincts.

Element: are the logical components of a project. Building projects fall into elements that follow a typical cost estimation breakdown: at the highest level these area underfloor, superstructure, weather envelope (roof and external envelope), site works. These further subdivide, depending on the complexity of the building: internal divisions, circulation shafts (stairs, lifts, ducts), fittings, services (electrical, communications, sensor, fire, HVAC, any industrial services), the external envelope has windows, doors, attachments, etc.

Elements are represented by Systems: these are the delivery vehicles of the project and break down into sub-systems, objects, assemblies, sub-assemblies and components (here we interface with the world of BIM). They are subsumed into system sets and systems of systems.

[An example of a system breakdown: Environmental system set, HVAC system of systems, air conditioning system, air handling sub-system, air filter object, filter assembly, filter frame sub-assembly, filter barrier component. If a smaller breakdown is needed, we can use component-parts.]

Materials are next, and vary from project to project. All projects need a materials dictionary that details each material specified and its use. Working schedules (e.g. the finishes schedule) can then refer to this dictionary).

Suppliers: the firms that supply components and materials, and

Operators: the firms that install, erect or place materials and components.

All these are brought together in the Work Breakdown Structure, shown in the construction drawings, described in the construction specification and performance criteria, delivered according to the schedule.

During the project, with its tempo dictated by the schedule, every piece of information, every issue, risk and question is 'tagged' with the relevant dimensions, and from each dimension the relevant information for that dimension's member is available.

The project team can check current outstanding issues related to, say, concrete sub-structure in the N-W zone of building Z for pouring by ConretePourers P/L. with a reference to the concrete for this location in the materials dictionary.

Nothing gets lost, all information can be tracked, and tied to the WBS and schedule, cross linked to the risk breakdown structure.

Nothing is buried in separate documents that have to be individually tracked, opened, read and copied from. Everything is linked to the 3D model of the building/s in terms of the schedule and WBS.


What software to support this?

Trimble's Prolog (it used to be Meridian's Prolog), or Primavera Expedition went some way, but I know of nothing at the moment that supports this type of functionality at the level of detail I want.

For my own work I tried using Zoot, which was good, particularly for indexing documents. Right now I'm experimenting with Infoqube, which replicates aspects of EccoPro, and bears some resemblance to Lotus Agenda, which I used decades ago.

Other packages I've tried are UltraRecall and, on the Mac, Devonthink.

Saturday, March 21, 2020

The very big project

Familiar project structures typically include a PCG: project control group (or Project Board, in Prince2)

In large projects I've conducted I find a couple of other formal groups useful:

1. An Operational Management Group (OMG, or OMCommittee), and
2. A Stakeholder Reference Group (SRG)

Operational Management Group
On complex projects, the sole manager, even with staff is not adequate to the complexity of the operational activity. The OMG is composed of the decision-makers from essential contributing disciplines or departments. It usually runs to 5 or 6 people.

The OMG role is to advise the PM/PD on critical issues of coordination, operational strategy and the details of performance, again, particularly where coordination is required.

In smaller projects, the PCG can reach into this area, but in larger projects, it concentrates on policy and strategic matters, and authorizations of critical decisions related to scope, expenditure, and policy.

Stakeholder Reference Group
Large projects can have many conflicting stakeholders, stakeholders that the project genuinely seeks to serve in some way. The representatives of these groups meet every 6 to 8 weeks to consider progress, the relation of the project scope and performance requirements to evolving stakeholder concerns and needs and to advise the OMG of stakeholder interests. The OMG may refer these concerns to the Sponsor for further consideration, with any project effects being referred to the PCG/Board.

Tuesday, December 25, 2018

On tenders

There's no end of advice on calling and evaluating tenders for building/construction services, whether professional or trades, it would seem. This is suggestive of a problem not yet solved.

One of the most popular approaches is to seek tenders that satisfy listed performance or capability criteria and achieve the lowest price while demonstrating high performance. Quite a tension!

In the UK the desire is to fine the Most Economically Advantageous Tender ("MEAT") where price and performance criteria are melded in the hope of representing a meaningful measure of overall benefit to the principal.

As in other places, the performance criteria are usually given some type of qualitative or impressionistic but hardly objective, repeatable or reliably reproducible score. The various criteria are then 'weighted' by an equally subjective and probably unreliable method. The 'dartboard approach' to tender evaluation.

The prices are 'normalised', removing information, and the result is multiplied by the weighted performance score and it is imagined that knowledge is produced!

Patrice Fabien has written on this topic with some insight into its limitations.

I'd like to propose a better way than the hit or miss that is common.

The performance criteria need to be characterised by sub-criteria so that the evaluation can be objective, with scores given on the basis of countable items. For example, running from:

0 = meets no sub-criterion up to
5 = meets all major and minor sub-criteria.

The weighting is best achieved using a system such as pair-wise analysis, as explained in the MITRE STEP methodology, and precisely in the evaluation system.

In my view, this produces a reliable and reasonably objective performance or capability score for the project performance.

This score is then subjected to a threshold for progression to the price evaluation.

The threshold might be set as an absolute minimum acceptable score, or minima that must be achieved on a number of criteria. Thus a low score on identified criteria will eliminate the tender from further consideration. After all, there is no point considering an offer that fails to deliver, no matter what the cost!

The next step is the price comparison.

Only those scores that meet or exceed the threshold should be considered at this point. If there is a large field over the threshold, a 'countback' through the scores might be used on a criteria basis (tenders with lower scores on critical criteria eliminated or only the highest 'n' scores considered.

Rather than mathematically normalise the prices (which destroys important information) to produce a 'score' then multiply this and the performance score, it is preferable to proportion scores against the lowest 'above the threshold' price.

This proportions the price by performance, in effect, pricing the performance.

The result looks like this:

Sunday, December 2, 2018

Good Design

Lots of talk about 'good' design. But precious little on its parameters. Sometimes the 'good' transmogrifies from effectiveness to moral rectitude, touching other way-stations on its travels.

There are a few lists around of dimensions of good design.

One of the most famous is Dieter Rams' 10 principles by which good design is:

  1. Innovative
  2. Makes a product useful
  3. Aesthetic
  4. Makes a product understandable
  5. Unobtrusive
  6. Honest
  7. Long-lasting
  8. Thorough down to the last detail
  9. Environmentally friendly
  10. As little design as possible
Some of these are meaningful. Others are empty, arbitrary or judgemental. For instance, "honest." Really? "Unobtrusive"? Not good if you are designing the entry to the Emergency Department of a hospital. "Aesthetic"? Aesthetic what? Good, bad or ugly...they are all 'aesthetics'. Aesthetics is about beauty, it doesn't mean beauty itself. "Environmentally 'friendly' ". Peurile and unhelpful.

Archdaily sets out a little more description on this same list.

Here's another attempt.

Parsimoniously fit for purpose.

Easy to say, hard to do. That covers 1, 2, 4, 7 and 9 of Dieter's list.

Let's look at the coverage:

1. "Innovative" without purpose is waste. The wheel is good, but we innovated to tracks when they were better. Tracks on a racing car would be no good! Innovation for its own sake without a driver external to the object of attention is also waste; and possibly frivolous. On the other hand, if it takes us to unexpected benefits or stimulates external unexpected benefits, opportunities and investment, then all the better.

2. "Makes a product useful"

Of course, 'fit for purpose'. Noting that the wider 'purpose' is cast, the more better (!) the design is. The best design is produced on the back of deep understanding of all the drivers of purpose. These can range from an investors' objectives, to users' objectives, usability, lifetime costs, usable life, the applicable objectives of others who have in interest in the subject...and so it goes.

4. "Makes a product understandable"

Same as previous.

7. "Long lasting"

Better: lasts as long as necessary. A stage built for a temporary festival that would last 1000 years is not what we want...although some stages build for permanent use have lasted well over 1000 years.
If it lasts too long, the risk of over use of resources or over investment in the subject occurs.

9. "Environmentally friendly"

I've never known what this means, nor does anyone else, I suggest, as it is used to promote all sorts of political and commercial agendas.

Here's what we are after: Meets environmental requirements and in an overall sense, parsimiony of materials, effort, operation and ownership leading to minimal consumption of resources: just enough consumption to meet the user need, and just enough consumption through maintenance and cleaning. There is also a cost-performance trade off with any measures that are not core to the purpose of the design subject. Over-investment in one 'environmental' outcome will reduce the capacity to achieve other environmental or general product outcomes.

Uses inputs (materials, components and execution techniques) compatible with requirements.

This meets Dieter's 7, 8, 9, 10.

The core parameter is cost-effective deployment of industry capability. This can include innovations that are brought about, of course, but it is hardly good design if a product is impossible to achieve economically or with other consequential 'dis-benefits'.

Nothing meets number 6. To help think about 'honesty' in design, compare the 'honesty' of a CT scanner without the cover. Honest? Helpful for an anxious patient? Easy to keep clean? I don't think so, and darn scary when it starts spinning.

Enjoyable to own, use, operate.

Dieter's numbers 2, 3, 4, 5, 8.

Enjoyable is hardly the word; perhaps enjoyable for the use: a hospital foyer's 'enjoyable' would be able to reassure patients, encourage staff and attract visitors. An opera house foyer: enthrall, excite, stimulate?

Enjoyable relates to practicality, affect, and aesthetic perception appropriate in the product's context.

Thus, in keeping with Dieter's number 10 my list is 3, his is 10. Less is more.

Another take on lists is my five item version:

In every way suiting the needs of the users, owners and investors: even the needs they don't realise for functional fit, comfort, future adaptability, etc.

Again, in every way: value for money in selection of materials, systems, components, operations, maintenance and future adaptability. This is an umbrella 'economy' including use of energy and maximisation of passive climatic adaption.

No mucking around by the builder and his supply chain to realise the design.

As above in the list of three. This can go from 'merely' comfortable, to spectacular, depending on the building's role.

This is as broad as you need it. As one uses, passes by and/or views the building, what it does, is and provides to the place, the user and its viewers is comprehensible. That is, the building represents its performance 'strategy' to the user and community. This can extend to contextually adapted (a 'good neigbour'), 'coded' for its purpose by the visual/tectonic and spatial language of the design, tells the user what the user needs to understand: where one does what. For example the entrance presents itself to the user for comfortable and helpful usage (back to 'usable'). An opera house, conveys that it is a special, fun and enjoyable place to be, etc.

Saturday, August 18, 2018

Programs and programs

My recent work has included a lot of interaction with human services businesses. They use the word 'program' differently from its use in generic project management; indeed, even the public sector based Prince2 system conceives as programs exclusively in such terms too. (in the MSP system).

In human services, 'program' when it is not applied to infrastructure, for example, the hospital construction program, means, not a collection of related projects, but a systemic intervention to bring change in people's lives; the 'people' are usually known as the 'target group' (in the Army we used 'target' to mean something we would obliterate...not so here, of course!).

These programs are based on what it terms a 'program logic model'. This sets out how the program will work to effect the results in peoples lives that it sets out to achieve. Conceptually much like an infrastructure project.

The PLM works back from the results to 'Inputs' via (in backwards order): Outcomes, resulting from Outputs, resulting from Activities, detemined, or defined by Resources or Inputs selected on the basis of Need or Opportunity.

Again, there is an obvious resemblance to the typical project course.

Where the major difference is is in the Activities-Outputs-Outcome set. This trio is a constant cycle that operates for the duration of the program, and may be a permanent operation, for all practical purposes. For example, the 'road safety program'.

The PLM is not only a plan (at high level) but a means of inquiry into the program; so it forms the basis for definition, specification, design and delivery; much like a schedule; but brings together schedule, WBS and delivery in one unit.

A typical PLM is below.

Wednesday, August 15, 2018

Top level project report

I posted this comment on a recent Linkedin PM forum, to the request for the items that a CEO report should contain for a project.

At the very top level: the current forecast outturn cost, compared to current budget; the current forecast completion date, compared to current approved completion date; earned value status, dollars committed, number of unresolved issues in an aged table (e.g. unresolved for 2 weeks, 1 month, 2 months) and current value at risk.

 Now for some detail.

The critical information for a CEO is how much will this cost and when will it be finished. This 
would be compared to either the business case or the current approved state of the project.

Reports should have a graph of all previous forecasts to show trends.

 A subsidiary interest would be the expected NPV of the project compared to the business case, or current approved NPV. For some CEOs this would be critical. Indeed, for all, it should be!

Earned value status is an obvious one; but if a formal EVM system is not used, it can be given an approximation: how much was estimated to be spent for a certain state of production, compared to how much was actually spent. If the contract has an estimated cash flow, this could be an input to tracking this.

However, all these are backwards looking. The CEO would need to have information about the project's future.

Two proxy indicators that could be reported are:
  • dollars committed (that is, subject to contracts with suppliers and sub-contractors). Comparing these against cash flow projection can be used to assess the project productivity.
  • aged tracking of issues from the issues log. The number of  open issues over time would give an indication of the general project state and performance. If notified issues won't do it, then it could be decisions pending, or contractor claims unresolved (i.e. yet to be agreed, accepted or rejected).
The final item is current value at risk. I'm assuming here that the project has a quanitified and costed assessed risk. As the project advances, some risks retire, and the final project cost becomes more secure in a tighter range, but others may emerge, change or be costed more accurately. This might lead to an increase in either the final out-turn cost or the expected range of that cost (e.g. project is 80% certain to cost between $10m and $11m). 

An example of a similar report format is below, for illustration. It is also worth referring to the One Page Project Manager for another, more operational, approach.