Revolutionising Solution Delivery: The Power of Artefact Driven Delivery

Artefact Driven Delivery is a method of solution delivery, created at Familiar, that focuses on using artefacts as the main unit of progress, instead of tasks. This approach avoids the Cost of Delay, deferred feedback, and other risks associated with traditional approaches to solution delivery. Approaches which delay work on implementing a solution until all requirements, designs, etc. are fully defined. Instead, skeleton standard artefacts are available from the beginning of the solution development process, are based on standard templates. The artefacts are then gradually filled with solution-specific content as they are needed for implementation and delivery.

The standard artefacts used in this approach include the Control Document, Articles of Understanding, Glossary of Terms, Statement of Purpose, Case for Action, Vision, Folks That Matter and their Needs, Risk Parade, Top Risks, Functional Requirements, Non-functional Requirements, Critical Success Factors, Feature Schedule, Quality Plan, Test Plan, Change Control, Cycle Plans, and Cycle Reviews. These artefacts are continually shared with clients and serve as a running history of the endeavour.

The Artefact Driven Delivery approach follows the Antimatter Principle which is covered extensively on my blog. For the curious, the “Javelin” White Paper provides a more in-depth explanation of each of the artefacts.

In conclusion, Artefact Driven Delivery is a method of solution delivery that emphasises the use of artefacts as the main unit of progress. It avoids the risks associated with traditional approaches, by establishing standard artefacts from the beginning of the solution development process and gradually filling them with solution-specific content as needed.

This approach results in a running history of the solution development and better communication between clients and the development team.

Building Things

We could describe my whole career as one of building things.

Early on, these things included software, hardware and tech products such as fax servers, compute clusters, compilers, interpreters, network systems, operating systems, development languages, applications, databases, and so on.

Later, things morphed to building teams, communities, software development and delivery groups, business units and tech companies.

Most recently, the things I build have morphed again, into techniques, approaches, tools and know-how applicable to building things.


This post is mainly concerned with sharing some of the insights I’ve gleaned over the years. Insights into effective ways of building things:


When embarking on building a new thing, I choose to dwell for a while on the purpose of the thing I’m building: Who’s it for? What will they use it for? How will they use it? What needs do they have that this thing willl address?


What does the Needsscape look like? How can we anticipate it changing over time? And how will we monitor and respond to those changes?


Doing things with a clear understnading of where those things fit in the scheme of things. Rather than just spinning the wheels for the sake of feeling busy.


Answer the question: “How will we ensure that what we’re building manifests the quality/qualities needed by all the Folks That Matter?


Manage all key risks facing us in bulding the thing (and in deploying, using it too). See Tom Gilb’s “All Holes In The Boat” principle (any one key risk can sink the whole effort).


Build things in small increments. Get regular feedback from all the Folks That Matter, early and often. Whilst continually remaining open to the system-wide impact of what’s being built.

Clarity of Communication

One can never have too much communication. One can never have too much clarity of communication. I prefer to use Quanitification as the means to improving clarity of communication.

Make Things Visible

Particularly with the kinds of things I’ve been building over the years, things nebuluous and more or less invisible most of the time, it helps to find ways to make e.g. progress visible and clearly understandable to all the Folks That Matter.


Often called the Shewhart Cycle or Deming Cycle. PDCA (Plan-Do-Check-Act) offers a conceptual framework for building things:

  • Plan what we’re going to do in the next days or weeks.
  • Do stuff according to that plan.
  • Check how well we did stuff (identify shortcomings)
  • Act to address some shortcomings in our doing, so that the next cycle’s doing goes better.


Deming banged on about the necessity for people to have pride in what they do. I find pride is enhanced through people feeling they own what they’re building.

Build Less

Build as little a possible. With the lowest tech possible. Commensurate with meeting folks’ needs. Remember YAGNI.


I don’t expect the above list to be of much use to anyone. Because, normative learning. C’est la vie.

– Bob

Who’s Delusional?

When it comes to organising the development of software, someone’s delusional.

Maybe it’s me. Despite proving my philosopy and practical apprioach (Quintessence), honed over nearly 30 years of real-world experience.

Maybe it’s you. Clinging to your outdated and unproducive approaches, be they waterfall (batch and queue), or Agile.

Maybe it’s the managers and executives. Doing the same thing year in and year out, expecting different results.

Maybe it’s all of us.

How do you see it?

– Bob

Tarred With the Brush of Excellence

I note a widespread aversion to the idea of “doing things properly”. Not just in the software industry, but also in wider society.

I’m not going to define what “properly” for software development looks like – although I have done so at length in my latest book “Quintessence”.

It’s as if people associate excellence (doing things properly) with higher costs, more effort, and a likely higher boredom factor. 

Whence these associations, I wonder? In my mind, doing things properly implies lower costs, less effort, and more joy in the doing. If not, then how could we describe it as “properly”?

How about you? What’s you take on folks’ responses to “excellence” and the idea of doing things properly?

– Bob

Further Reading

Peters, T.J. and Waterman, R.H. (1982). In Search of Excellence: Lessons from America’s Best-run Companies.  Profile Books.

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).

It’s not that we don’t know how to design, build and deliver software solutions reliably, predictably and on time. It’s just that those involved don’t want the bother of doing things properly. It’s much easier and more comfortable to just futz around. There’s always sufficient budget to not have to worry about the economics of software production. And lives are cheap.

Quintessence First Version Now Available

The first release version of my new book “Quintessence” is now available for purchase on LeanPub.

With this book I’m rewriting the whole field of software development management. About time, you might say. :}

This version is some 8% complete. I’ll be adding to it progressively over the next few weeks and months. I invite your early comments, suggestions and questions.

– Bob

I find it risible that many software groups refer to themselves as “engineers” and to what they do as “engineering”, when they have no idea what “engineering” actually entails. And in particular, when they make no effort to assess and control software risks (development risks and product risks, both).

See also:

Jones, C. (1994). Assessment and Control of Software Risks. Yourdon Press.

Koen, B. V. (2003). Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving. Oxford University Press.

Demarco, T. & Lister, T. R. (2003). Waltzing With Bears: Managing Risk on Software Projects. Dorset House Pub.

Announcement: New book “Quintessence” In The Works

I’ve just published the Leanpub placeholder for my next book: “Quintessence”. First iteration (likely, 8% complete) will be published soonest!

I’d be delighted if you’d visit the page and express your interest!

– Bob

We might forgive junior software engineers (a.k.a. junior developers) for being ignorant of many things. The field of software engineering is both broad and deep, and it takes many years to come up to speed in all necessary aspects. Indeed, I have seen many engineers with even 10+ years experience having major blind spots and shortfalls in their knowledge. Are the latter “senior engineers”? Many of them bear this title. Outwith my issues about titles, I posit that there are numerous topics, mastery of which is require to fairly assume the title of “senior engineer” (hint: coding skills are but one of some fifteen or twenty such topics).

See also: Scope Of Ignorance

The Inklings

In a previous life, I was charge with leading a whole passel of software and product developers. To help create an environment where they might wish to up their game, I proposed and launched a new community called “The Inklings”. I attach the proposal and launch announcement hereunder, for your delectation/misery.


Inklings Proposal

Launch Announcement

Inklings Launch Announcement

NB These two documents have been edited/redacted/dates and names changed, to protect the innocent.

If you’re wondering how it went: I left the company shortly after, and no one took it forward.

– Bob

%d bloggers like this: