Indispensable Project Management Artifacts and Activities

Organization and Human Factors | Progress and Practice

I was recently reminded of the minimal set of project management artifacts and activities that are, in one way or another, simply indispensable.

None of this is news: all of this has been well established for at least 25 years (a quarter-century!), so I was surprised that apparently it is still not common knowledge or practice — at least not as common as one would wish for.

The point in all of this is not primarily to have the artifacts, but instead the process of preparing them. It is the need to prepare these documents and to conduct those activities that forces everyone to think things through. It is the “thinking through” that matters!

Remember: “Plans are useless, but planning is indispensable.” (Eisenhower)

Technical Documents

Project Statement, Project Description
  • Describes the goal of the project, in brief.
  • Depending on the complexity of the project, this may be short (one paragraph), but it must be sufficiently descriptive that a person unfamiliar with the effort can get a sense for the undertaking. “Redo the XYZ report” is not enough!
Func Spec, Feature List, Functional Description, Product Requirements Document (PRD)
  • A relatively detailed list of features.
  • Each features must be clearly scoped and of meaningful granularity (about one week’s worth of work). Greenfield and infrastructure projects may have larger work units; incremental enhancements to an existing system may have smaller ones.
  • For UI projects: appropriate UI sketches or designs.
Tech Spec, Architecture, Implementation Notes
  • Again, depending on the complexity, this may be short (one page), or much longer.
  • At a minimum, there needs to be a list of technical tasks to be completed, systems affected, and so on.
  • An informal sketch of systems and message flows is often surprisingly helpful: not so much for people on the project, but for outsiders to grasp what the project is all about.
Optional Documents (depending on project complexity):
  • Risk list (if there are particular risks or unknowns).
  • Non-functional requirements (SLAs, uptime, security, and so on).
  • Success criteria, CTQ (Critical to Quality), KPI (Key Performance Indicator): how will we know that we are “done”? This may be obvious — or not!
  • Roll-out or deployment plan (this may be implicit, or part of the tech notes).

Project Management Documents

Project Plan, Feature List
  • With estimates and dates!
  • Establishes a sequence of tasks and dependencies.
  • Individual features must be small enough that their scope is clear.
Contingency Plan, Staged Releases, Time-Boxed Development, Fallbacks
  • What do we do when things don’t go to plan or schedule?
  • Spell out cut-off dates and conditions.
  • This can be rough (by the time we will get there, things are guaranteed to have changed from the original!), but the discussion is necessary!
Escalation Plan
  • Whom to involve when the project team itself can’t achieve a solution.
  • Among conflicting stakeholders and their priorities: who decides? Who can make a go/no-go decision?
  • In most cases, this will be implicit, but it is better to be clear early. If this is ever needed, it will be too late to figure it out then!

Activities

Kick-Off
  • Clearly state what we do, when we want to finish, who participates.
  • Yes, this is required — everyone needs to know that we are doing this.
  • Make sure to involve all participating parties at this point!
Coordination and Task Assignment
  • This must be done. In a functioning team, this happens automatically, but in a less functional (or simply: bigger) team, some explicit coordination is necessary.
  • Do not assume this happens, be clear.
Progress Monitoring and Adjustments
  • This requires the feature list, with dates.
  • Without monitoring, there is only Activity, but no sense of Progress.

What is a “Document”?

I use the term “document” throughout, but the format is essentially arbitrary: a whiteboard can be remarkably effective! (I remember a project where the project team had to move offices — and took the unwiped whiteboards with the project plan off the wall to take with them.)

What is essential, however, is that some of these artifacts are persistent: their purpose is to make it possible to go back and review the Project Statement, or the Feature List, or the Tech Notes as the project moves forward and its state and the state of the environment, inevitably, change. This is impossible if documents are in constant flux or entirely fluid — there needs to be a sense of stability. (How else will we be able to determine success?)

For this reason, a set of Jira tasks or Yellow Sticky Notes is not sufficient — although either of them will be great to track progress on a day-to-day basis. I also find it impossible to get a sense for the overall scope of a project from a bunch of disjointed sticky notes or Jira tasks. At least a few comprehensive artifacts that pull everything together are simply necessary.