Four (or Five) Critical Project Questions

Mike Clayton has a short video on (the) four important project questions.

It's a good list for the PM running the project:

1. What is getting in the way of each member of your team doing their very best work

2. Which elements of your project are not as fully in your control as they should be?

[about 'control' of the project in its environment: where you can gain more control to achieve the sought value from the project's completion.]

3. What are you not thinking about that could have a material impact on the future of your project.

4. What is the question you are not asking? Obvious question? Question we avoid?

I thought one was missing, particularly in the light of project influencers (so-called stakeholders, who don't usually hold an actual stake in the project)

My 5:  Who is most likely to get in the way of the project delivering the value sought  by its owner?

I managed one project where a major contributor to the project made all the noises of support, but failed to connect his team properly with the project plan. The project sponsor helped, but not much. I had to 'go round the outside' to get things done.

This seemed to be a nice idea: bring the project critical questions to one place. I checked a few other sources.

Team Gantt had quite a good set.

Core question #1: What are the major deliverables?

This question forces you to be clear about what you want to achieve when embarking on this project. Moreover, you can use this question to check if you and your project team are working within scope and that each step you take leads you to those deliverables.

Core question #2: How will we get to those deliverables before or by the deadline?

This question requires you to think strategically to be able to create or achieve these major deliverables on time and on budget.

Digging deeper, you may want to consider the possible changes or risks that may affect your ability to meet these requirements. You can then devise solutions to work around these events and stay on track.

No matter the industry or the type of project you're working on, you need a project plan that will map out how you, your team, and your stakeholders will get from Point A to Point Z. Tools, like gantt charts, ensure that you complete projects on time, but also on budget. ?

Core question #3: Who is on the project team, and what role will they play?

This question addresses a crucial aspect of any project: who will be the people you’re bringing on board to help you complete the project?

You need to be clear on who your teammates are, how they work, and what role/s they’re to fulfill. A RACI chart can help you ensure each person is clear about their responsibilities during the course of the project.

Core question #4: When will the team meet milestones?

...and when will other members of the team play a role in contributing to or providing feedback on those deliverables?

Your project timeline should answer this question. This is where you’ll plot the deadlines for each specific milestone and decide when the team will come together to discuss progress and updates and who will either work on or provide feedback for specific deliverables.

Plenty Training had quite a good set

1) What is this project all about?
2) What does my project sponsor/client want me to do?
3) What are the implied tasks I am being asked to achieve?
4) What are the limits/boundaries of my authority?

You need to ask these questions so that you:

    Are given an idea of the project and organization context.
    Can find out what result the client really wants.
    Can find out if you are being given full responsibility and authority.
    Know exactly what power/authority you will have throughout the duration of the project, especially when it comes to decision-making.

After asking these questions, you should know:

    What your sponsor/ client is really after in regards to the project.
    What you are allowed to do and say.
    What authority you have for the duration of the project.

By asking these four key questions at the beginning of the project, you are also building a foundation of trust between yourself and your client/sponsor, which is absolutely critical!

Quay Consulting starts to tighten the question and heads toward the nub of the PM's concerns

Question 1 – Do We Know What Success Looks Like?

Sitting within a project that is under significant stress can ignite the initial ‘fight or flight’ response in all of us. It can be the prompt for a deep dive into the weeds, such as the schedule, to see where we can make up time or look hard at the dependencies that can be delayed to help the team re-establish the baseline and bring the project back to green.

Question 2 – Are we doing everything necessary to deliver on the success?

This is a critical question that the project manager needs to be able to answer. As they explore the issues relating to the project, it’s essential to revalidate that the scope can deliver the promise.

Question 3 – Are we listening to the right voices in the team?

It can be incredibly difficult to ignore the noise in a project to refocus on governance as a barometer for staying on track. When the PM and the team are under sustained pressure, then there will be a lot of noise being generated around the project, often from mid-tier management, related projects and field staff. PMs need all their energy to stay focused on the task at hand.

Question 4 – Are we really leading our teams toward success?

Leaders are born in times of crisis. When a team is looking for direction, a safe place and a common goal, it’s vital to not lose sight of the fact that the team is impacted by the noise and often without the full situational context.

Now, Glen Alleman takes us to the prize parameters for project management

1. What Does Done Look Like?

What are the Measures of Effectiveness (MOE), Measures of Performance (MOP), Technical Performance Measures (TPM), and Key Performance Parameters (KPP) of Done?

2 How Do We Get There? What is the Plan and Schedule for reaching Done?

3 Do We Have Enough Time, Resources, and Money to reach Done at the needed time for the needed cost, with the needed Capabilities?

4   What Impediments Will We Encounter Along The Way?

What are reducible (epistemic) uncertainties and irreducible (aleatory) uncertainties, creating risks resulting in implements to reach done as needed?

 5 How Do We Know We Are Making Progress?

What are the processes and procedures to measuring the Physical Percent Complete of the deliverable produced by the project? What is the confidence this progress to plan can be maintained and be assessed in the Estimate to Complete and Estimate at Completion for time, cost, and technical performance.

Conclusion

1. Start with Glen's set.

2. Apply Team Gantt's list

3. Use Mike's list to keep you on track.

The others are OK, perhaps for simpler projects, but keep these three in mind for all projects, particularly in the initial project collaboration symposia (a.k.a. 'workshops).

But of course, make good preparation:

Clearly set out and tested 'concept of operations' that the project has to address

Develop Work, Element and Risk Breakdown Structures to organize the project

Create a risk-adjusted delivery schedule, with stage acceptance parameters.

Ensure the Project Board/Sponsor is interested, attentive and supportive.

Project Breakdowns

Most of us are familiar with the basic project planning analysis: the Work Breakdown Structure, the document that shows the taxonomy of subdivision of the basic specialist product of the project into component work packages. It is used both to assign responsibility, in larger projects, and to check with the sponsor and users that all the required work appears to be included.

But, for a fulsome approach to project management a number of other breakdowns are essential.

Function Breakdown Structure

This analyses the functions that are required of the product into a logical hierarchy to ensure that all the headline functions will be acknowledged in operational functions.

This is then used as the basis for preparing performance requirements and acceptance standards for work packages and feeds into the design specification and performance parameters.

Risk Breakdown Structure

Same for risk. to ensure risks are understood in the most useful operational detail to enable proper analysis of hazards and effects.

Element Breakdown Structure

This breaks the product into its element hierarchy. This is a check on the FBS, but also provides a 'dimension' for keying project deliverables, specifications, inputs to elements of the final product.

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.

Easy!

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.

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. 

Project predictions

Most of the formal measures we have of project performance (including progress) are backward looking. They report what has been done, sometimes when it is too late to bring corrective action to bear if performance is below expectation.

There is plenty to do to avoid project mistakes: credible baselines, to borrow from Glen Alleman's blog, are a big part of it, as are achievable requirements, risk-adjusted planning, the right team, and so on. That's essential to project performance.

All well and good, but how do we look ahead?

I recently received a newsletter from Charles Pellerin and this turned my mind to the project social climate. Like any business undertaking, projects are delivered socially: that is by people working together to achieve a common goal. Social climate, the sort of thing that Charles writes and practices on, is a large part of determining project success. There are social climate instruments that in expert hands could provide a useful insight into project outcomes. But a wise PM can also maintain observation of social climate: what issues, risks and decisions are coming to him or her, and how quickly are they attended to: a good rule of thumb.

In $300m major urban renewal project that I directed some years ago, I used 'aged decisions' as my rough guide to the performance of the team (reaching across a number of government and private sector players). It also gave me something tangible to open conversations to prompt performance when a decision remained unmade for an excessive period.

Another way of looking at it, is to consider promise reliability: measured by promises delivered. Following Hal Macomber's work in the old Reforming Project Management blog (some of the material might be found on the Lean Construction website); the tracking of promise keeping is an indicator, a robust one, in my view, of project delivery reliability.

There are others as well. In a contracting environment contract commitment against plan is a useful forwarding looking metric, for example.

Project Success

I recently presented on Achieving Project Success.

Most discussion on this topic that I've heard wanders around matters related to requirements, definition and budget.

But there's more. Sure those topics are important, and neglected will frustrate success, but they are not sufficient.

Others discuss project processes: particularly relying on the setting of acceptance criteria at relevant points in a project: for deliverables, but also for completion of capability elements.

Again, neglect here will frustrate success, while attention itself is insufficient.

My talk covered three topics, some absorb the matters above, but I took a more global project view:

Project Success Baseline

• Objective and requirements set out in sufficient detail.
• Contract distributes risk on basis of control and avoids risk switchback during construction and concession phases. Risk allocation adjusted for phase based role changes between the parties.
• Contract sets out governance between parties, performance monitoring and control provisions.
• Principal recourses include step-in rights, performance bonds, contracted dispute procedure, termination.
• Suitably experienced contractor and management for type and size of project.
• Suitable and adequate financing structure for contracts used (such as construction finance and operational payments).
• Cooperative contracting approach with regular project ‘conferences’ to maintain tempo and performance.

Project Governance

• Project Board (senior reps of primary parties, Principal is chair) to overview performance and approve ‘stage gate’ progress. Meets at and between stage gates.
• Project Control Group (reps of delivery parties, Project Director is chair) meets at least monthly to review progress, risk rolling wave (risk retirement, treatment, and emergence) satisfaction of milestone and phase acceptance criteria.
• Constant review of project performance climate: risk events, communication and cooperation between parties, critical stakeholder and participant views against project conduct criteria.

Project Control

• Earned value reporting on pre-concession phases, with forecast of milestone achieved dates (to identify slippage) and corrective actions to be taken.
• Tracking of sub-contacting commitments and performance
• Review of progress and performance by Principal, SPV and financiers, reported to Principal.
• Value reviews to ensure appropriate investment in performance of product and implications for concession period operations.
• Principal retains visibility of sub-contractor procurement methodology and performance.
• Periodic reviews of deliver project management performance.
• Project level relationship between Principal and providers maintained through formal and informal reviews of performance.

The triple constraint

I used to disparage the triple constraint: I thought it simplistic and unhelpful.

The three constraints (triple, because they interact) are illustrated below.

 
More recently, this has been elaborated into a double triangle: attempting to be all things to all people describing project factors, rather than the constraints.

The elaboration is unnecessary. Risk, resources and scope go to budget, budget and scope go to schedule, quality goes to scope. There are probably other schemes, but they end up in the triple constraint quite quickly.

Risk as a factor is interesting...its like putting 'doing your job' as a factor. Risk is assessed then used to guide the setting of budget and schedule against scope. Scope is quality.






I like Glen Alleman's much more helpful diagram, below. He introduces the concept of 'technical performance measure. Much more meaningful then either 'quality' (as if that means anything), or scope.

My preference is for a modified triple constraint, that is more attuned to the business environment and the realities of projects where a project exists to produce a capability that has value for the sponsor.

I've adapted Alleman's TPM to be 'objective', although 'performance' as the out turn result of the project is what we are after. Fussing around with 'quality' as the centre of the triangle does nothing for anyone; what we need to focus on is the value produced (to meet a certain performance by a certain time to produce value from the investment: think Net Present Value).

The money is invested; its not just a cost, but the investment has to be carefully managed to ensure that the sought return achieves the necessary value. We don't manage 'time'. Alleman is right, that we manage schedule, but I prefer to use delivery, as this focuses attention on the project doing what it is meant to do: deliver value.

Stoplights

After gantt charts, the next favourite topic of communicative techniques is the project 'stop light' chart. Three colours (red, amber, green) to give a 'high level' view of project performance. However, they are criticised.

On a real project (any decent sized construction project), I've never seen anything as puerile as a stop light pretend chart. I've seen detailed status reports.

There are only two main parameters for projects (once we've established the sought performance of the product): out-turn cost (EAC), and date of (defect free) completion. One could also report drift in the parameters, and if there are unmade decisions creating schedule or cost risk, the EAC and DFC date could have probability ranges attached. Not that a board will pay much attention to the implications of either: best convert them to a date range and a cost range.

On the other hand, some people seem to love RAG status reports. Maybe because they remind them of lollypops...I can't think of a grown-up's reason to like them.