Guiding Principles 1: Business Value

The 'Executive Board' website has a list of 10 guiding principles for project management.

Over the next couple of months I plan to comment on them. The first is below.

Business value: The goal of all project work is to deliver business value.

How does a company move from project lip-service to project commitment? In my base expertise area of construction, its pretty easy: a new retail centre is tangible. More difficult in a business project where the result might be changed processes, a different perspective on the business environment, the approach to planning, product development, market engagement, etc.

But even where a company touches the construction industry, if it is a rare experience, the business must be self-aware about the project it embarks on.

How would it do this?

It needs to provide a project governance structure that connects the project to executive information and decision making systems (you do have those, don’t you?).

The investment-value equation has to be managed carefully, to get the business results from the project, and that will enable the decision to abort a project that has become a ‘good money after bad’ experience.

Interfaces with other parts of the business have to be managed to support the project on the one hand, and sustain and develop the ‘business as usual’ commitments on the other.

Just Do It!

In the brave lands of TV shows, Hollywood cinema and advertising the world is easy. This is famously captured in an old Mickey Rooney film where a particular financial crisis is dealt with by the exclamation "Let's do a show!"

Its that easy.

In the world of business and projects the same type of thinking makes its way, chillingly, across board room tables.

It pops up in seminars and the structured enquiries that we like to call 'workshops'.  It happened to me yesterday.

The moderator of the session ('facilitator') attempted to break an impasse by a Mickey Rooney moment. He asked why didn't we 'just do it'?

I could tell that it wasn't his money on the table.

Just do it? Without a clearly stated business purpose, without an assessment of the scope of the action or the definition of the subject of the action. No mention of costs, resources, or even a structured appreciation of risk or competitor reaction...no, the Mickey Rooney way was was the best. Leave your mind at the door, toss your experience out the window and just go broke. Not go for broke. But without passing go...go broke.

Best Practice

This is becoming a habit: my turning over of meaningless business jargon with the reality of projects.

"Best Practice" is the next on my list.

All I can ask is "Who is it 'best' for?"

If its best for this project, let's test it and find out; but better, let's work up the project delivery team to produce processes that will be the 'best' for the project through educated critical process checks, system refinement and check again on the results.

That is, we engage the intelligence and experience of the people doing the work, informed by others, but not slaves to what someone else in some other circumstances thinks is best for my project. A project they've never thought about, let alone seen.

Design Thinking

The Multidisciplinarian has a post on 'design thinking'.

It covers a lot of good ground, including having a stab at the 'fadism' that pollutes business discourse. A short time ago...a few years...'design thinking' was the beaut new thing to boost the revenue of consulting firms who are ever eager for solutions to their declining revenue opportunities as the last beaut thing fails to deliver. It often fails to deliver because it fails to deal with the interests of the customer, and prefers to pander to the needs of management, but that's another story.

In the building industry I meet and work with architects and engineers all the time, so encounter 'design thinking' and design talking, as well as design doing also all the time.

There are probably many varieties of 'design thinking' but the factor that I think may connect them all is the discursive use of resources to meet the requirements that will give life to an opportunity.

Note I avoided the word 'problem' and the phrase 'problem-solving'. I doubt that design is fundamentally a problem solving exercise. To characterise it as such is trivial, although architect-instructors at university use it all the time:

Practicing architect: "I'm designing a library."
Academic architect: "What's the problem?"
Librarian: "The problem is that there is no library!"

See? It gets us nowhere.

Rather there's a need and an opportunity.

Design occurs when resources are marshalled to meet the need. It entails meeting a set of criteria that may be changed as they are explored and challenged during the design process. It entails varying the 'power' of criteria as the work proceeds. This might include solving problems by employing tradeoffs and compromises, but that's on the way, not the object. The object is to realise socially useful shelter that meets the need, speaking at the broadest.

As the Multidisciplinarian points out that 'design thinking' is not magic, but usually proceeds when there is no obvious means of meeting a need or taking an opportunity, or realising a return. A parametric envelope is created by user requirements. As the response to the requirement set is developed, the parametric envelope, and the options available close in on a result. At bottom there is probably no strict algorithim to do this, although architects and engineers do have algorithmic-like behaviour as they develop their designs.

That's part of the craft of design in the building industry.

The Sensible 12: No. 12!

12. The project must deliver the expected value to the customer.
We all know a project is measured by successfully delivering the scope on time and within budget. I believe the true measurement is successfully delivering value to the business or customer. Value
encompasses all three of these components: scope, schedule, and cost (as well as quality). The value to the customer will not be realized unless the vision of the project is met.

This is the only reason for the project; if it doesn't occur, then the customer will not be back.

ASAP 2

In a previous post on this noxious abbreviation that pollutes business conversations, I decried the imprecision of its use.

I had another encounter with it today. The rational explanation for the fool hardiness didn't work, so I replied:

"OK, my 'possible'. I'll let you know when."

Kind of like the so-called 'reverse brief'; the document you give to a client when they don't know what they want (all quite legitimate in the world of the unknown). My rejoinder drove home the point that in a project where schedule sets the tempo of activity, dates have real meaning, measured in $ of value produced in NPV terms. Muck up my dates unpredictably and that will muck up your project returns unpredictably.

So, as a good PM, I'll let you know the date that is possible while maintaining the project tempo to produce the value you've hired me to produce.

The Sensible 12: No. 11

11. Issues and risks must be addressed quickly and openly.
Every project has risks that are associated with the venture, and every project will have issues that surface along the way. The fact that they occur is not unique, however, how they are addressed is unique to a successful project. It is critical to identify risks at the initiation as well as throughout the project. Immediately upon identification of a risk, develop a plan how you will manage that risk. As issues occur, address them quickly and provide the appropriate visibility to shareholders. Providing
transparency of risks and issues is an important principle of managing a successful project.

This along with communication is the meat of project management. But let's be sensible and approach risk management particularly with an understanding of the probability of risks, from analogous cases, and how to meet the potential cost on a 'diversity' basis. But fundamental is that the project is designed to eliminate as many risks as possible; and that shows up in the schedule!

The Sensible 12: No. 10

10. A change management plan must be in place in preparation for the inevitability of change.
Change is nothing to be afraid of; in fact if it wasn’t for change, there wouldn’t be a need for project management. The key is to have a change management plan in place which describes how a request is submitted to the project and how you will manage that change request. If this plan is documented and understood by all shareholders, change will be managed without disrupting the project.

I don't know what 'in place' adds to the content here. Yes, you must have a change management plan and the sponsor must participate in the development of the plan. He/she must also promptly give (or not) the authorisation of any changes (along with any investment and schedule changes) in cognizance of the benefit/value they will provide to the project.
The plan should include change proposal evaluation criteria to prevent the inclusion in the project of whims that do not go to the mission, but absorb time and resources nonetheless, depleting the project out turn value.

The start of a project

It would be pretty obvious to most working project managers: a project starts with a business need; or a 'mission' if you like that kinda language.

The impluse of some is to rush to a scheduling package and start making up dates for actions that they think will progress the project to an end result.

Not so fast: a lot hangs of the mission that needs to be developed before one can understand the components of the project to achieve the mission and deliver a business benefit.

The most important item that develops from the mission is the description of the technical performance required (what will the project's deliverable do) and the criteria by which one would know that the required performance has been achieved. Only then can one develop the project components, create a work breakdown structure, analyse that into activities and produce a schedule.

But there's something prior to these details.

For a project manager to deliver a project he needs to establish the capabilities needed to create the deliverables. This goes hand in hand with developing the WBS and possibly comes before the budget. Development of the budget comes from an interplay between capability, technical performance it can produce, schedule and business benefits. The PM has to have a bright eye to trade-offs and how value can be created and delivered by the project.

The Sensible 12: No. 9

9. Project processes must be effective and efficient.
There are two types of processes: those that add value and facilitate repeatability and reliability of a series of tasks, and those that only get in the way and waste time. Projects that are successful must embrace and continually improve those processes that add value, and get rid of those that waste time.

Its right, but I just find the phrase 'add value' to be cliched. I was once asked to give a referral for a contractor I'd used and the prospective project manager asked me if the contractor had done what was required. They had. Then I was asked if the 'added value'. The implication was that they'd done something extra for free. So I had to explain the economics of production to the dill on the phone: yes they added value because they did as they were contracted for their $100k fee. That's the value they added! There's no magic in commerce.

ASAP

A favourite abbreviation in the business world is ASAP: as soon as possible.

I hope that this doesn't become a favourite in the world of projects that I am familiar with as its a recipe for disaster.

If you think you've got schedule risk now, then it will amplify when everyone starts talking the unparametrised language of "ASAP".

For me 'as soon as possible' means 'when it fits into your schedule'! Not what the sage head that sets the empty target is thinking, I'm sure.

If you have a delivery date, give it. Set a deadline, and I can work out the resource and production implications of your request; absent those, the request has no temporal parameter, and I'll do it as soon is it is MY possible; not yours! And that does not equate to 'quickly', 'urgently' or lets play the 'we're the fire brigade now' game.

The Sensible 12: No. 8

8. Communication both internal and external to the project must be clear and frequent.
Almost every aspect of project management is facilitated by the written and spoken word. It is critical that team members communicate often with each other as they work to fulfill the vision of the project. The project manager must communicate progress that the team is making toward their deliverables as well as surfacing issues and risks that arise along the way. It is important that all communication inside and out of the project clearly conveys the appropriate message to the intended audience.

Information is the lifeblood of project success. Much of the discourse on projects is about delivery or schedule; doing things. This is right as far as it goes, but the right things must be done rightly. People need information to do this and need to provide information while they are doing it.

Everyone on the project team must feel free to get any project information they need, and contribute to the project as they see is necessary. That is, no conversations (about the project or its performance) are prohibited. Once freedom of project information and communication is reduced, the  project manager is cut off from knowledge and there's nothing that stands in the way of failure.

The Sensible 12: No. 7

7. The project manager must serve the team.
The project will be successful only if the team succeeds. The project team consists of individuals who are blessed with their own strengths and skills. It is important to get these individuals to work together as a team to deliver the service or product which will ultimately provide value to the customer. Team production increases as the project manager serves their team members by doing things like removing road blocks, facilitating resolution of issues, and in general supporting their every need.

Again, no. The project manager serves the project sponsor, his/her investors and their customers. To do this he or she does all the above, but let's not forget that individuals join a project team voluntarily (that is, they are not conscripted and can walk out the door at any time) and expect the project manager to perform his or her role while they perform theirs.

The Sensible 12: No. 6

6. The project manager must provide leadership for the team.
The project manager must provide leadership to the project team helping them evolve into a cohesive unit with a clear understand of the project vision. When successful, the team will be able to deliver greater value to the customer than what would be achieved by a leaderless group of individuals.

No. The project manager must manage the project. He or she will facilitate, provide resources, identify the work load, manage stakeholders, report, recommend action, provide information, or catalyse others to obtain information, and above all, will use thier position to move the project along.
Mature professional adults do not need 'leadership' as some exercise of moral superiority, they need coordination, common understanding of roles and responsibilities, and a focus for information and advice. If they are not performing, a conversation is required to identify the concern and resolve it.
Sheep and dogs have leaders, adults in a cooperative social endeavour (work) do not.

Project Management is an Information Game

Nice to see this reflected in one of Glen Alleman's recent blogs: The Value of Information.

In a way, its a commonplace: all we have in any intellectual or social endeavour is 'information'. That's not a special observation. However, what is special is how rarely this translates into common understandings of project management or how the related estimates of risk, cost, delivery performance are made.

A lot of discussion seems to refract PM as a time and/or cost (usually 'time' if the way PM is coupled with scheduling computer packages) game. Well, these are clearly part of it in the real world where both are limited, or constrained, but the project grows and lives (and succeeds) on the good management of information.

The Sensible 12: No. 5

5. A team that takes ownership in the project will deliver successfully. When a team takes ownership in the project with the enthusiasm to deliver increased value to the customer, that project will be successful. It takes soft skills and leadership by the project manager to foster a unified team, but when successful, great things happen. A team is most effective when they understand the project vision and can gain a passion for the solution and take ownership in delivering that solution.

All fluff. A team doesn't 'take ownership' unless they are investors; pretend 'ownership' is a bit of pop-management rhetoric.
The people who are engaged in delivery have to be committed to their promise to do their job.
The Project Manager has to provide resources, direction, and the organisational setting to facilitate this. We all need to behave honourably, politely and with respect. End of story, or its the end of the story.

Project dimensions

In Karl Wiegers' book "Practical Project Initiation" he includes an approach to developing a view of a project's constraints.

The starting point is to map the 'five project dimensions' on a kiviat diagram (radar chart) showing their degree of flexibility.

Wiegers sees that the 'iron triangle's' three project dimensions are inadequate, and if stated as 'time', 'cost' and 'quality' he's dead right. But he re-engineers these three into five (see the illustration from his book, below): features, quality, cost, schedule, staff. There was a question as to whether 'risk' was a project dimension. Of course, it isn't; it is a characterisation or qualification of any of the legitimate dimensions and doesn't have an independent existence or basis apart from the subject that is at risk.

But is five better than three? Does it help?

My first reaction is that 'quality' is a fake dimension, and 'features' perhaps as well; (although in software development, maybe its meaningful). These two attempt to split out the one parameter that has basic meaning for the project's mission: '[technical] performance'. If I need performance at 'n' for a project, then the only 'quality' I'm interested in is in 'n' being achieved. If there's an acceptable range, then it is the performance range, not a separate thing called quality range. So performance accepted is not just 'n', but anywhere between 'n-m' and 'n+p'.

'Quality' as an add-on extra to production is unhelpful and only serves to create an add-on industry of 'quality' advisors.

The two dimensions of 'schedule' and 'staff' are also related, and I question the split. However, I can see the sense operationally, with the use of the five dimensions is to establish the constraint envelope. If schedule (I think the term 'delivery' is better, it carries a reminder that the project is there to produce things, and not just to formulate an abstract schedule) is highly constrained, then staff flexibility might be nice to know, but possibly irrelevant; on the other hand if staff is a constraint, and delivery is flexible, then so what?

BTW, I'm glad Wiegers uses 'staff', not 'resources'. Staff are people, iron ore is a resource.

So, for me, the constraints to a project, or to a work package in a large project, come from the requirements for delivery, and this is probably related to interfaces with other work packages, the performance requirements and mission the project is to be used for, and the funds available to be invested for an expectation of return (I prefer to talk business, rather than accounting).

The Sensible 12: No. 4

4. The project must deliver a quality product or service.
There is no sense in embarking on a project unless the quality of the product or service that results from that work meets or exceeds the expectations of the customer. Even if the project is delivered on time, within budget and with the defined scope, it will be a failure if the quality isn’t there. Quality should be considered from the beginning of the project and at the forefront of everyone’s mind throughout the project.

Quality is a fake forth factor in projects. The only 'quality' is that the technical performance is delivered when required to produce the return sought (they always go together). There is no separate 'quality' parameter!
If technical performance is not achieved, the project is not 'done'. "Quality" then becomes an irrelvant overlay.
For example, a door has to stay on its hinges and latch shut when closed. If it does not  do this, then it is not that it is a 'poor quality' door, but that it is not functioning as a door at all. There is no door if the lump of wood won't swing on hinges and latch closed.

The project machine?

In his post on Better Projects Jon Whitty reports on a mini-experiment that he ran (write up here) on people's drawn responses to projects: kind of like art-therapy, I suppose.


He said:

What I discovered from this simple experiment is that our perceptions of project work is (sic) massively distorted by the various common artifacts (billboards if you like) of the project management community. The Gantt chart is a prime example. It reflects very little of the project experience ahead. An itemised to-do-list would do a better job. And in many cases I’ve found this is actually what is used.

It would indeed be a concern if people mistook the artifacts of project management for the conduct or the outcome of the project! It's also amazing that a gnatt chart and not a network of some kind is the representation of choice for a project's activity sequence.

If people are so wary of gantt charts, I am led to wonder if a quantified delivery risk is applied to each activity, or each work package, and if this is accumulated at stage gates for tracking (as per the critical chain method), and if there is a firm grasp of the outcomes and how they are to be firstly achieved, then measured. That is, what do we need to do and how do we know we've done it?

But, more than this disquiet, the enquiry betrays a machine view of projects, when this is as far off the mark as one can get.

It is naturally possible to model and run a project using some machine like representations, but these are only the documentation of a community process and represent an abstraction required for the organisation of the more intense and responsive discourse and joint action. And, no, I'm not going 'touchy-feely' in using this language, but being fair dinkum. A project is done by a collection of people, in various contractual relationships moderated by a joint desire for (mutual?) success. It is this informed interaction that gets projects done. It is the work of, what I like to call, a 'community of intent'; characterised by communication to find resolution and progress.

This has attracted various terms over the years, but I find the thinking that Hal Macomber used in his Reforming Project Management blog, and that David Ing at Coevolving Innovations refers to to be on the right track.

Just think about a project you've been involved in (I mean a serious project, not the kiddie stuff that recruitment agencies sometimes refer to): if it is anything like one's I've worked on, it is run by lots of meetings and less structured conversations, a zillion e-mails and phone calls, and a high degree of flux; sometimes at a frenetic pace. All this is done in the light of the theme expressed in the formal documents and representations; which, in a well organised project, will be updated continuously and in the light of the outcomes sought and risks met and dealt with.

In many ways this is like the work of general management (see Henry Minzberg's various writings on what a manager really does); its artifacts are similarly uninformative about the work: cash flow statements, production schedules and balance sheets; but few people mistake these for the business.

Jon gets down to the to-do list and hangs his hat on it. Well of course. Day in day out, its a simple list of what you need to do, or what the project needs to achieve that lubricates activity. In construction this is the 'look ahead program' (a similar concept is commercialised in the Last Planner method): the next two or three weeks' rolling schedule done in great detail to co-ordinate interfaces between work packages and project events.

In my experience a project is produced by the complex information flow between participants, organised, themed and paced by a set of artifacts that recognise the limits of information and contraints of risk properly quantified and expressed.

If you want to talk to upper management about a project, you've got to use risk talk and not let them get locked in to a too neat gantt chart that over-simpifies reality and ultimately mis-informs them. As Glen Alleman insists, quoting Tim Lister: risk management is how grown ups manage projects.

The project triangle re-jigged

I fluctuate between supporting or avoiding the 'triangle' project badge. My no. 3 post on 'the sensible 12' touches on supporting with modification. But its hard to get past Glen Alleman's representation of the triangle: more informative and more useful, in my view, and including risk in the project structure, just as it should be.

For convenience, the diagram is copied below.

The Sensible 12: No. 3

3. The scope, budget, and schedule must remain balanced throughout the project.
In project management there is a key concept called the triple constraint or the project management triangle. The idea is that while managing a project the project manager must keep three constraints in balance; the scope or work that is required to produce the projects end results, the amount of time required to perform the work, and the cost or budget for the project. Scope, time and cost are almost always competing constraints. Typically, you cannot change one constraint without affecting one or both of the other constraints. The key principle is that as change happens, you must keep these three constraints balanced.

As a rough rule of thumb the 'iron triange' is a useful aphorism, but it is not good business to take just a 'cost' view of a project. Any project is an investment of resources and effort over time; the investment has to give a return to the investor that is better than alternative investments. The question is investing to produce business value through achieving the required performance (or delivering the required capabilty).

Sure, any project decision will have implications for expenditure, delivery and performance, but 'scope', 'budget', and 'schedule' is only part of the story. The project manager has to manage the whole story, including the value sought to produce the investment return. The PM has to be concerned with the outturn value of the project as a result of the delivery efforts.

So, I prefer to frame a project as investing (cost) to deliver (schedule) capability (scope) to maximise return (value).

Let's go 'all thumbs' on this one.

While I'm on the fumble theme, another project nightmare. But worse, ye gods: this one killed people!

It wasn't crippled by 'dodgy' installers. It was crippled by rushed policy, lack of industry consultation, imagining that a group of politicians and their child advisors could just jump into a business, no evident risk management...they didn't even appear to know that there were risks. It was hubris writ large!

And this in a country with a sophisticated construction industry with architects, building professionals (the white collar guys I mean) and engineers like grass seeds: everywhere! And, I might add, a public service that, at least in the states, includes highly industry-aware staff that design industry engagement schemes day in and day out, and successfully.

How more wrong could it go?

In my local municipality, the council has been building a re-developed aquatic centre for nigh on two and a half years (give or take) for a project of, about $12m.

It is badly over due for any reasonable completion time (it was advertised as 12 months), having commenced in January 2012 and has attracted attention as a result. Understandable given that multi-hundred million dollar retail centres don't take that long!

The council has explained it thus:

The construction is a complicated project and is taking longer than expected due to a number of factors including:

• earlier wet weather during demolition and excavation
• poor ground conditions
• the unavailability of key construction components including the pool hall roof, forcing a redesign,
• tweaks to the design along the way brought about by design clashes and improvements being incorporated into the final product
• and the availability of the key subcontractors that will make this a quality product.

Now, an acquatic centre, while moderately complex, is a well known type of facility and should be able to be reliably delivered.

Just looking at the council's explanations for delay, it looks like a few fundamental and frequently made mistakes may have occurred:

'Tweaks to the design' and 'design clashes: They scream out "we rushed". Not enough time or effort into pre-construction, we did the design on the cheap, we didn't let the consultants use 3D clash detection, we probably didn't budget properly and we didn't have effective project launch workshops (links to three firms I've dealt with).

Wet weather? There's always wet weather, and we should always allow a delivery contingency for it. Not merely a 'stab in the dark' but something that's based on meteorological records. They're available for free from the government!

Poor ground conditions? Basic risk; that's why we do ground tests and retain geotechncial engineers, then use them to guide footing design. Skip this step and you are up the creek before you know it.

Contractor availability? Basic procurement risk mis-management. Or was the head contractor on such a skinny price, that he didn't have a secure hold on his subbies? Either way, the liquidated damages provisions of the contract should ensure that the rate-payers get their damages back.

Component availability? Design management not done well for this to occur. Were the 'hard to get's' specified instead of practical design being the objective? I don't know, but in a mature industry, I'd think that one has to go out of one's way to specify components that would bring delays.

None of which is, as they say, 'rocket science', but good building project practice that has been developed over decades. There are plenty of practitioners who would have easily got it right; but then, that requires an investor that will take advice; and that may be the nub of it. Particularly when the investor is not familiar with the building type.

The Sensible 12: No. 2

2. Planning is critical to success.
The most critical part of a project occurs during the planning stages. A successful project is preceded by careful planning including the identification of the tasks which when executed will meet the vision of the project and deliver value to the customer. The plan should include provisions for impending risks to the project as well as contingency for unknown risks. Additionally, it is wise to be prepared for and be aware that change will be introduced into the project…be prepared to change the plan.

Risk management is usually a tack on to a project, but planning has to include uncertainty: and that gives rise to risk. So the plan on any project of any decent size has to allow for the variability of estimates of cost and time for completion of project activities. The 'contingency' for unknown risks is wishful thinking. We don't know, so how do we allow for it? We can only reasonably allow for what we know of the type of project, but cannot evade the investor's risk that all projects have. It just might not work that way! How could Sony have 'managed' the risk that the market would prefer VHS to Beta video taping?

Planning flows out of project definition and relies on a high degree of certainty of understanding of the capability that is required of the project.

Project dimensions

Looking on the web-based project management offerings, I'm coming to think that many are designed for projects that I would regard as trivial: you could manage them with either bits of paper, or Excel. They don't seem to lend themselves to what I regard as a serious project. For me that means large construction projects: retail, industrial and institutional projects of at least $100m.

The life-blood of managing these projects is the information torrent.

Matters of schedule, expenditure and performance are there, of course, and set the 'tempo' and objectives of the project, but to get things done, information management is what happens day in and day out.

I conceptualise these projects along two basic dimensions: the project breakdown, and the work breakdown. For spatially large projects there's a spatial breakdown too. For example, a retail centre will fall into a number of organising zones: food court, groceries precinct, major boxes (for the large department stores), fashion precinct, car parking (which will be subdivided in most cases by location).

An industrial complex might fall into warehousing, administration and amenities block, production, packing and distribution.

Hospitals fall into a number of units too, for large campus developments: medical services, wards, ancillary services, research and education wing, etc.

Dimensions

The two basic dimensions which apply irrespective of size are the project elements (the parts of the project) and the work packages (how the parts get delivered).

Elements are unrelated to schedule but organise information, work packages are schedule related and organise activity.

In projects I've applied this scheme to I've thought that the hierarchy of elements can only realistically go 3 or 4 deep, and not across the whole project, or its gets unwieldy. In practical terms the hierarchy has generally been 2 deep, elements being subdivided into items, such as the element 'external works' broken into items: site preparation, bulk excavation, paving and line marking, planting, site services (lighting, drainage, water reticulation, service mains, services diversions, security and communications), retaining structures, fencing, signage.

Work packages are large units of work that deliver a completed project component, or sub-project in some cases.

A work package is delivered through 'activities' (these are the things that usually appear in a scheduling application like Primavera, they roll up into work packages, or summary activities quite easily).

To complete activities a number, sometimes a large number of tasks are done, such as the activity 'clear site' might require the tasks: remove vegetation, protect structures and trees, remove refuse, install siltation barriers, etc.

In summary we have: Elements --> Items; Work packages --> Activities --> Tasks.

Thus, one can see how trivial Web-based 'project management' applications that facilitate 'tasks' have to be; they do not and often cannot put tasks into a useful project context.

Now, how do they relate?

Using examples from construction, in some cases a work package will be identical to an element. For example, the 'external paving' element could be delivered by a single work package for paving (although at the element level, 'external paving' could comprise both vehicular and pedestrian paving, which could be two different work packages, or more, delivered in different locations or at different times, even if done by the one contractor). In some cases, a work package and an 'item' might have identical coverage. More usually an element would be delivered through a number of packages: 'external envelope' could be delivered via work packages for brick laying, curtain wall, glazing, external doors, louvre installation.

Some of these might be items. The item 'external doors' would usually be delivered by a single work package.

Activities could be aligned with 'items', but this would not always be clear cut. The item 'external doors' could be delivered by a package for external door supply and installation, but the item 'water mains' might be finally delivered through a number of work packages: site clearing, bulk excavation, trenching and shoring, mains diversions, pipe laying and connections. In brief, work packages tend to relate to elements, and tasks typically relate to items, but they are not always 1:1 relationships and one does not always exhaust the other.

'Elements' and 'items' serve as means for compiling related production data and project information for consolidated views of the project by its management and delivery teams.

For the manager, the two hierarchies allow selective visibility of progress, but allow risks, issues, documents and changes to be attached to elements for a comprehensive view of factors affecting the project at any time.

The Sensible 12: No. 1

The Sensible Project Manager provides a set of 12 Principles of Project Mangement. This is way more than Glen Alleman's 5 Immutable Principles, so...is that better or worse, or just different?
Over the coming weeks I'll comment on each of the 12, with the first now:

1. The project vision must be clear and agreed to by the stakeholders.
The first principle to success begins with understanding the vision or goal of the project. There is a reason the project was initiated and the project manager as well as all stakeholders must understand the business need and what success looks like. Make sure that all stakeholders understand and agree to the project vision.

This looks right, but the language is too fluffy to turn into action. What is a 'vision' when it comes to a project? Better that a project have a clearly defined busines value with the means of realising that value built into the project. The project must have a stated mission to achieve, and a definition of the capabilty that the project will produce.

This will flow straight into the funds that can be made available, it sets termination criteria to avoid throwing good money after bad for a project bound for failure, and allows objective acceptance when 'done' is achieved.

Vision is fine, but you'd better know what the capability of the product will be and its cost if you want to stay in business.

Then, as part of the work of the organisation, the project has got to be supported by the organisation as a whole, otherwise mission critical will be turned into mission aborted. The IRR on aborted missions is a negative number!