Adam on Projects (Volume 1)

Section Index

Click on the links below to jump to a summary of the axioms in each section.

On Project Success

The primary goal of any project is to achieve success. However, success can have different interpretations depending on many factors, such as the project methodology used, past experience, personality type and so on. These distinct
definitions of success demonstrate how a seemingly straightforward term can have multiple contextual interpretations.

Axioms:

• # 1. The source of project success. - Project success flows from people thinking and working naturally together.
• # 2. Successful projects? We've got both kinds! - There are only two kinds of successful projects: sponsor signed off and explicitly shut down.
• # 3. Why do projects fail? - Projects fail because we make them fail!
• # 4. If you want your project to succeed, move your ass! - Elapsed time is the most significant source of risk in most projects.

On Projects & Project Management

The concept of a ‘project’ varies widely depending on your perspective on industry, profession and even general life paradigm. Yet the concept of a ‘project’ at its most generic is the seminal organising framework for all human goal-seeking endeavours. Projects are the natural way people think and work together.

Axioms:

• # 5. The power of the dog. - The power of a model or concept is inversely proportional to its variant count.
• # 6. What is a project? - A project is any endeavour established to enable an outcome, as, when and how determined by its stakeholders.
• # 7. Be the right kind of project manager. - Be the kind of project manager who believes their job is to enable successful outcomes for their stakeholders.
• # 8. Practice Minimal Responsible Intervention. - The overriding management principle for a Project Manager must be Minimum Responsible Intervention.
• # 9. The last resort custodian. - The project manager is the last resort custodian of the outcome.
• # 10. Shut the fuck up and listen! - Shut the fuck up, and listen!
• # 11. The critical skill for a Project Manager. - The critical skill for a Project Manager is the ability to obtain an outcome.
• # 12. Be a Gowachin Project Manager - Act like a defence lawyer who will get the same punishment as their convicted client.
• # 13. Projects are everywhere! - You can improve every human endeavour by viewing it through a project lens.

On Agency

Agency refers to the imperative for individuals and groups to act, choose, take responsibility, and reflectively make progress. Agency is the engine by which any project gains forward momentum, allowing team members to prosecute the project’s objectives. "Agency" beats "Autonomy" every day of the week, and twice on Sunday.

Axioms:

• # 14. Proceed until apprehended! - Proceed until apprehended!
• # 15. First Action! Then see what happens. - First Action! Then see what happens.
• # 16. Every project has its own natural cadence. - Every project has its own natural cadence that drives the pace of work, which cannot be easily changed.
• # 17. There are two contrary forces in the world! - In the long run, the forces of the bazaar will always overcome the forces of the cathedral.

On Enablement

We talk endlessly about projects “delivering value”, but the reality is we don’t deliver value: value is not something that can be delivered.
The concept of project enablement holds that the value of a project is not what you deliver, but the enhanced capabilities of those using those deliverables to capture value within their context, e.g., an organisation in a particular industry.
Thus, projects enable value, not deliver it.

Axioms:

• # 18. Do you have a system-based objective? - If you're not thinking of the entire end-to-end causal value chain, you're wasting your time and their money.
• # 19. Understanding the cost of delay. - If you don't understand the cost of delay, then you don't understand anything.
• # 20. Always be looking for the $1.95 solution. - Always look for the $1.95 solution, even if it's just a reference point.

On Evolution

In a project sense, evolution refers to the various ways in which knowledge and practice emulate the process of natural evolution. Understanding the conceptual model of evolution is fundamental to managing successful projects.

Axioms:

• # 21. Everything in every project evolves! - Everything in every project evolves, regardless of its lifecycle, methodology or context.
• # 22. Is there purpose in your iteration? - Iteration without purpose trends towards Brownian motion.

On Abundance

The Abundance / Scarcity mindsets, first popularised by Steven Covey, are now promoted by the spiritual guidance / lay psychology/self-help / personal growth coaching industries with gusto. Project "Abundance" is a practical extension that describes the positive mindset that a project will be able to find a successful outcome and will obtain the resources it needs.

Axioms:

• # 23. Abundance is the soul of your project. - Abundance is the soul of your project - without it, you\'re just turning the dreary handle of process.
• # 24. A project is a bridge. - A project is a bridge to an unknown but envisioned future.
• # 25. The Long Corridor. - A project is like a long corridor of untold locked doors.

On Agile

The term “Agile” in a project context (usually software development) is a lightweight approach that emphasises the evolutionary satisfaction of customer value needs through the rapid development of output using an iterative “inspect and adapt” cycle by small hyper-collaborative
teams. The reality is often different.

Axioms:

• # 26. Just because you want to do agile doesn't mean you can. - Just because you want to do agile doesn't mean you can or should do it.
• # 27. The triple helix of Agile evolution. - Successful agile endeavours must evolve along multiple distinct but related threads.
• # 28. The saddest oxymoron of the 21st century. - A team wanting to perform adaptive agile as it was intended must leverage every ounce of their courage and values to make it work.

On Requirements

Although the term “Requirements” is rooted in more traditional methodologies, it’s just a general term covering all statements of intended outcomes and impacts the project will enable. All projects of any methodology or lifecycle approach must be grounded in non-technical
statements of intended value for the “customer”.

Axioms:

• # 29. Do your customers' answers confuse you? - When gathering requirements, if your customers' answers confuse you, then ask better questions!
• # 30. When tech folks talk to business folks what language do they speak? - All your project conversations should be in the language of the business domain.
• # 31. Non-functional requirements are a secret weapon. - Non-functional requirements are ten times more valuable than functional requirements, at least.
• # 32. A false separation. - You cannot separate Functional requirements from Non-functional requirements; they are endlessly and critically interconnected.

On Software Packages

Software packages, whether implemented “on-premises” using customer owned infrastructure, or as “Software-as-a-Service” cloud-based or hosted solutions, are an important and much-used solution strategy. The premise of a software package is that pre-built software is high-quality and addresses the common needs of customers in a specific functional or industrial domain. If only it was that simple.

Axioms:

• # 33. Why did you buy that software package? - You'd better have a better rationale for buying that software package than because you read about it in a consultant's market report.
• # 34. If you can't define the enabled behaviour. - Using a software package implementation as a forcing function to define requirements is a fool\'s game.

On Project Debt

You may be familiar with the term “Technical Debt”, but there are other debts that your project can incur, often without the project manager knowing about them. The meaning of “Technical Debt” has evolved since it was first coined in 1975, and now has “spalled” to the point of being unhelpful in a project context. It’s not the job of a Project Manager to understand the intricacies of the term or the definitional debates. It is the job of a PM to help the team navigate through that dissonance, so they can do the needful.

Axioms:

• # 35. Where did you borrow your TechDebt? - You borrowed TechDebt from the worst kind of loan shark; it only gets repaid with sweat, tears or blood!
• # 36. The root cause of technical debt. - The root cause of all technical debt is the prioritisation of functional progress over non-functional capability
• # 37. There's a bigger problem in your project than TechDebt! - Business debt is incurred by making expedient compromises when defining and mapping the problem to frame it as a project.

On Assumptions

I’m sure you’ve heard this aphorism about assumptions: “Assumptions make an Ass out of U and Me”. The first time you hear that it is helpful and makes sense, it becomes useless through repetition. Assumptions are a fundamental aspect of successful and innovative projects, as long as they are well-balanced with our risk posture. Learn how to love them.

Axioms:

• # 38. Use assumptions to plug any hole in your planning. - Assumptions can plug any hole in your planning but don't fall in love with them.
• # 39. Supporting the bridge to an unknown future. - Both facts and assumptions support your project narrative.
• # 40. Assumptions have Boxian qualities. - Project assumptions have Boxian qualities (wrong but useful), but some are more wrong and less useful than others.

On Planning

Planning is a future-oriented activity designed to give each of us a way to achieve our goals. Planning is constant in every human brain. According to one researcher, intelligence is the ability to predict, and planning is a quintessentially human activity. There's nothing wrong with planning - in fact, it's impossible to avoid. The only thing wrong is not matching your planning to your context.

Axioms:

• # 41. To plan is to be human. - Planning is an innately human capability that we cannot suppress.
• # 42. Keep planning until you start making shit up. - Keep planning until you start making shit up.
• # 43. That unforeseen crisis your project is having? - That unforeseen crisis your project is having was almost undoubtedly foreseeable.
• # 44. Planning is linear, but execution is non-linear. - You must understand and manage the project paradox: planning is linear, but execution is non-linear.
• # 45. The false foundation for detailed forecasts. - If your detailed forecasts are supported by estimates including "maybe", then you've gone way too far.

On Teams

Although individuals conduct many projects, the full benefits of a project approach come from doing them in groups. I’m not sure the opposite is true: can you have a team without a project? Regardless, we introduce complications as soon as we transition from one to multiple people, and almost all the narrative about projects is generated from how we resolve these complications. How do we marshal the collective resources of multiple people whilst reducing the impacts of the same thing? These axioms reflect my experience and philosophy on teams and teaming.

Axioms:

• # 46. A project is a lifeboat. - A project is like 12 people in an 8-person leaky lifeboat at sea.
• # 47. How do teams self-organise? - You can't "manage" a team to be self-organised.
• # 48. Stop rolling around in broken glass! - Endlessly worrying and bickering is like enjoying rolling around in broken glass.
• # 49. Project teaming happens quickly or not at all. - In the absence of hostile factors, the project teaming effect happens quickly or not at all.
• # 50. Every human action has a reason behind it. - Every human action is triggered for a reason, no matter how dumb or destructive it might seem.
• # 51. Actual activity vs displacement activity. - You need to be able to differentiate between actual activity and displacement activity.
• # 52. Business people make lousy solutions architects. - Business people make lousy solution architects.
• # 53. Beware the one-person "team"! - Beware of the one-person "teams" in your project.
• # 54. When your project team complains. - A team complaint might be the tip of the iceberg - or it might just be a lump of ice.
• # 55. What expectations does your team set for themselves? - The results of your project won't meet any higher expectations than those you and your team set for yourselves.
• # 56. Invest in alignment! - Investing time to get "on the same page" pays off at 10:1 or 100:1 or more.

On Risk

Risk is how people deal with the uncertainty of the future in a structured way. Projects are all about risk, so we couldn’t let this subject area go untouched by axioms.

Axioms:

• # 57. It's great to be the first penguin off the ice! - In a project, you\'re always the first penguin off the ice, so you may as well enjoy the swim.
• # 58. Everyone is fine with your risk management plan. - Everyone is fine with your risk management plan - until they get punched in the face!
• # 59. Why should every project succeed? - Projects are risky and uncertain, so why do we expect every project to succeed?
• # 60. Happy with your stand-alone risk management process? - Organic risk management structures in your project approach eat formal risk management processes for breakfast.
• # 61. The most common project WOFTAM. - Most of the energy and effort expended on Risk Management activities in projects is a complete WOFTAM.
• # 62. You need to manage Rissues organically. - Risk events that are so likely that you may as well treat them as having already occurred are called "Rissues".