Project

What Is A Project? An arbitrary collection of activities? It's definitely a Model (or the result of a Model; a Social Fiction).

It may be a simplification process of taking a messy Human System and pre-defining a vector of clear action with intended specific Outcomes.

see Project Management

Nov'2017: I'm feeling almost like the entire Project framing is self-defeating, so want to dis-prove that to myself... (context: Agile Software Development: see Nature Of Software Development) (possible claim-v2: Project process has value for some cases, but not others.)

What's my beef? (Anti-Patterns)

• the abstraction-hiding of each Project encourages multiple sets of them to be compared for use in a RoadMap or Project Portfolio Management set.
• Execs think they can just add those numbers and make staff level decisions a year in advance, and even order Projects to smooth out waves of different resource needs
• at that early stage there's very little accuracy or precision in cost or benefit numbers
• but those ballpark estimates tend to get treated like Commitments
• it encourages a single release/launch "at the end" rather than slicing off Increments.
• it encourages executing the plan without any ongoing Reflective Thought as to how likely the plan is to achieve originally-intended results (or whether the originally intended results still make sense).

Context of Pattern

• We want to invest time/money in non-routine activities to generate step-increase in outcomes
• (I'm thinking about more-mature companies that have a significant "routine" operation.)

Forces

• An organization has most of its people doing the same thing over and over (routine work).
• Almost all routine-Process Improvement results in incremental results.
• To get bigger results-improvements, you probably need to invest a non-marginal amount of time from multiple people in multiple departments.

Solutions: Agile Product Development

• Frame chunk of work as an explicit/written Hypothesis: "if we take actions A for time period B we will achieve operational changes C which will result in outcome (change in Metric) X". The inputs are a Project.
• Assign a single real Project Owner (aka Product Owner) (the typical Project Manager is more of a paper-pusher without power - beware that)
• Get everyone who will be working-on (or providing permission/resources for working-on) those actions agreeing to the Hypothesis, and agreeing to perform their set of actions.
• Slice the set of actions into a series of Increments, aiming to deliver the biggest chunks of Outcome first. (Maybe delivering Learning to test the Hypothesis is good enough, but I don't put much trust in indirect outcomes.)
• Every decision should be biased towards increasing the odds of delivering the Outcome. If this conflicts with the Hypothesis, ask if you should change the Hypothesis.

David Allen gives one definition. Any outcome you're committed to complete that requires more than one action.

• Merlin Mann gives his own spin after years of David Allen activity. Its projected outcome is valuable, desirable, and well articulated (even if it needs to change or adapt as the project’s constraints evolve). Everyone involved in the project understands and agrees on the project’s value and desirable outcome (or, failing at that, they at least understand what their role in its envisionable success must be).

Laurent Bossavit's thoughts

Sometimes it's about the boundary of a Contract or Commitment.