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.

Operations management

During my Christmas break, I've been exploring videos on operations management. Whatever your field: architecture, engineering, project management, construction, icecream distribution, you manage operations.

So, I went to the experts.

Lisa Bussom at Widener University, Eddy Witzel, and Inderdeep Singh at the Indian Institute of Technology.

I'm working through Lisa's content first.

In the second lecture, she talks about product 'attributes' and includes 'quality'. Quality is conformance to specification, in conventional conception. And sure, that's broadly an attribute of a product, but I think it is better to go to why the customer has an interest in the particular specification. They want a level of performance that will meet their need, their requirements, and give them value.

Performance is the attribute.

This then feeds into the process 'competencies'. Lisa has 'quality' as a competency. I would substitute 'design' for this.

Design is the threshold input to an effective process.

The genealogy of value is this: customer need/opportunity > performance to meet the need/take the opportunity > requirements to produce the performance > specification of capability > design to meet the specification, deliver the capability, produce the performance to deliver value to the customer!

Braess's Paradox, of why tampering never works.

My comment on https://youtu.be/cALezV_Fwi0

And this paradox is why randomly adding more people to a process (project, workflow, etc.) often fails to improve performance or output. It amounts to what Deming calls 'tampering' with the system. To change the result of a system, e.g. produce more quickly, the system needs to be redesigned.

The problem is?

Comment I posted on: https://youtu.be/u_JQs5CbP1U entitled The First Problem Every Architect Faces

Good review of the factors that go to siting a building. My practice has been that good buildings come from a thorough understanding of the purpose the client has, at a strategic level, the program (what the client needs/wants/is interested in) developed to achieve the purpose, the place and the people (client, users, customers, servicers, builders). Of course, what flows from this is the performance the building is to achieve. The 5 Ps of architecture!

But all that aside, I want to comment on the title: the 'first problem'. At uni my tutors always referred to architectural design programs as 'problems'. My colleagues still tend to do so. Engineers, bless them, solve problems, and sometimes very creatively.

Architects go further. We organize new potentials for people. So, the problem a city has is that there's no library in a neighborhood? Problem? The idea of 'problem' is reductionistic and turns architects into solution preparers -- like chemists?. This is a triviality compared to what we really do: find opportunities and make places for people to invent their futures.

We expand, we don't reduce. We create what has not yet been conceived. Doing that we solve a myriad of problems, or we avoid the problems, or we redefine them to exploit the benefits in an opportunity. A design commission is never a problem, it is always a challenge, an exploration, an opportunity, a desire.

Problem analysis

Systems such as the McKinsey system are good as systems in certain contexts, but they tend to be reductionistic.

1. Define problem - What key question do we need to answer?
2. Structure problem – What could be the key elements of the problem?
3. Prioritize issues – Which issues are most important to the problem?
4. Develop issue analysis/work plan – Where and how should we spend our time?
5. Conduct analyses – What are we trying to prove/disprove
6. Synthesize findings – What implications do our findings have?
7. Develop recommendations – What should we do?

A system better for architectural and many engineering projects might be modelled on Soft Systems Methodologies which start with the 'circumstance of interest', or the 'matter of concern'. General terms: there might be no 'problem' only options, or opportunities. There might be a better future than merely 'solving' a 'problem.

Analyse the circumstances using Rich Pictures and a 'CATWOE' study.

CATWOE is

Customers

Actors

Technology

World-view (or socio-technical context)

Owner

Environment (total socio-technical environment)

This can lead into a 'design' process that starts with outcome options, then works through constraints and pathways to develop options to create a new future.

 

 

Manage the 'inner' stakeholders

Stakeholder management, like most things in popular literature, is often reduced to a set of rules of thumb. Often good as far as it goes, but there are some stakeholders that need extra care.

I call them the inner stakeholders.

Who are they, and how do you find them?

Easy.

First, find the project sponsor. That's probably easy, but not always. The real sponsor.

Next find who the sponsor has dependency or supply relationships with.

That's them, then. These are the 'inner' stakeholders.

Because of their relationship with the sponsor, they have a stake in the project in some way. Maybe even a way they don't see or fully appreciate.

It's your job as the PM to find out what their stake is and how they conceive it.

You need to meet them and ask about the links to the project, and the links to the things and people, functions and customers, the project is linked to. The relationship of the 'stake' to the 'holder' can be a second or third-order relationship, and those relationships might then have similar links to other inner stakeholders. They all need to be found, named, and analyzed.

This is the group you need to get in a room and identify the interconnections and how their influence can be useful to the project (and therefore to them). A 'rich picture' can help do this.

Then keep them updated. Maybe weekly sometimes, maybe monthly or quarterly at others.

But keep them updated somehow, and keep your sponsor in the loop as an ally, a facilitator and a power and information broker.

No matter what. Do it.

The real project triad

Projects are about investing to delivery a level of performance that produces value for the investor. Everything is about this, including all trade-offs during the course of the project. It means everything flexes about value.

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.

Governance

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.