Documenting and Delivering your Project

Success comes from being clear about what you want and need, and ensuring you get it. Assurance comes from being able to monitor and report progress and performance against the plan.


In this article I want to explore how we discuss, decide, define and document what we need and ensure we get it. I use the term “what we need” loosely, but will explore business requirements, Specification Or Solution Design and various other artefact and steps from concept to completion.

To keep this simple I am going to talk about buying a car, but the concepts and documents can be adjusted to suit any project or change from technology delivery to expedition destination: are we clear what we want, and will we know when we get there?

Here is a summary, I will explore each point in turn below, noting the people, process and product that may be involved in each stage or phase.

*Business Requirements

First decide what you want and need. If buying a car is it a VW Camper or a Ferrari, what are the functions and attributes we are looking for? Does it need to tow a caravan and accommodate a dog and 3 children? Do we have a budget? Do we have a preference for diesel, petrol or electric? What about ownership considerations: parking, servicing, maintenance, resale value?

*User Stories

This is where we think about people and use of the item. If buying a car: will it be used for shopping; will it be used for foreign travel; will it be used for kayaks or caravan? Should it have a radio; wifi; maps; connect to your phone? Understanding how you, your partner, teenage children might use the car may influence your choice.


The acronym MoSCoW represents four categories of initiatives: must-have, should-have, could-have, and won’t-have, or will not have right now. Some also use the “W” in MoSCoW to mean “wish.” If buying a car: what is essential and what is optional, and what is unnecessary?

*Functional Or Technical Requirements

Aside from the business or user requirements, what people want, there may be some other compliance or technical requirements. Perhaps if buying a car emissions need to be below a certain limit, or electrical charging needs to be compatible with a particular style of charger. In business these compliance or technical requirements are often related to security, environment, data, compatibility and regulatory demands. They are additional to the customer requirements.

*Specification Or Solution Design
So now that you have moved through the steps of discuss, decide, define and document you are clear about what you need and can see what’s on offer. You might run an Invitation to Tender, a Request for Proposals, look at brochures or simply go to some car dealerships and see what’s on offer. The vendor, supplier, dealer or development business will offer a document, guide, specification, or similar for you to review, reflect, accept or reject.

*User Acceptance Testing

User Acceptance Testing can be as simple as a ‘test drive. For a car a pre-delivery inspection (PDI) is the final check carried out by the dealer on a car before they hand it over to you. During the PDI, the car is examined to make sure it is working with no mechanical issues and is ready and safe to be driven on the road. There may be a warranty or guarantee period to consider as well as payment and insurance.

*Hand Over And Close

For our car example there may be a difference between when you take possession (drive off the forecourt) and when you take ownership (when all the payments are made). If buying a house there may be a Snagging List of issues to be addressed after possession but before final payment. A Snagging List is a new build’s supplement to a property survey. It is a list of all the issues or ‘snags’ with a new build property, usually defects like damage to paintwork or small unfinished jobs throughout the property

In the following sections I will explore each of these areas in a little more detail noting the people, process and product that may be involved in each stage or phase, but still keeping it generic.


Business Requirements are a shopping list of “things” to be delivered, as opposed to tasks to be done. The term deliverable or product is term usually used. The PRINCE2 definition of a product is “An input or output, whether tangible or intangible, that can be described in advance, created and tested

The deliverable or product may be a Car, Computer or Cup. It is something for which you can agree success criteria and judge if it is acceptable. Often it is reviewed, signed, and approved to ensure it is valid.

Sometimes for intangibles like software or knowledge it is a document that gets delivered, like a Delivery Note, your MBA Certificate, your Driving License, your Passport, or your Exam certificate. There is clear evidence or achievement to the agreed standard.

When compilating the shopping list include all the stakeholders to ensure that all the needs are considered: customers, clients, colleagues. Perhaps include key functions like compliance, technology, HR, marketing. Perhaps also  include end-users, manager, support and the people who will be active owners, participants and users.

A facilitated session is a good way to progress discuss, decide, define and document.


User stories are often expressed in a simple sentence, structured as follows:

“As a [persona], I [want to], [so that].”

As a [type of user], I want to [perform some task] so that I can [achieve some goal].

As a cyclist, I want to track the location of my friends so that I can join them on rides.

Many teams use a structured approach for defining acceptance criteria. Here is a simple template to guide the writing of acceptance tests:

Given that [some context], when [some action is carried out], then [a set of observable outcomes should occur].

Given that the cyclist wants to ride with friends, when they check the map view then show them the location of other cyclists in their social network.

Asking key people to create ‘cards’ of their User stories may be a great way to get requirements from a variety of stakeholders in different departments.

Again, a facilitated session is a good way to progress discuss, decide, define and document.


Whether you have Business Requirements (a shopping list) or User Stories (a functional description) it is inevitable you will need to prioritise and compromise. The acronym MoSCoW represents four categories of initiatives: must-have, should-have, could-have, and won’t-have, or will not have right now. Flagging each item M, S, C W can be useful to clarify scope boundaries and priorities.


Like the Business Requirements Functional Or Technical Requirements may also be a shopping list, perhaps listing standards (like ISO 27001), qualifications (like ACCA 3 years post qualified), or compatibilities (import and export to Excel using ODBC file format.)


An invitation to tender (ITT) is the initial step in competitive tendering, in which suppliers and contractors are invited to provide offers for supply or service contracts, the ITT is one process in IT procurement. An ITT document specifies all requirements of the organization, including goods, services and timelines, as well as the evaluation process that will be followed.

A request for proposal (RFP) is a business document that announces a project, describes it, and solicits bids from qualified contractors to complete it.

The response from the vendor, supplier, dealer or development business should outline proposals, price and plan so that it is clearly understood what will be delivered, at what cost and when.

The proposals may include additional detail much like an architects drawing, which explains how the proposed solution might work. This could be a flow diagram, wiring diagram, technical specification or similar which can be very useful when assessing the security, data or compliance elements of a product where how it operates is as important as what it does.


You should aim to make your accept or reject decision based on evidence.  Indeed, the whole process is made easier if there is clear, concise, and complete documentation.

The PRINCE2 definition of a Product (or Deliverable) is “An input or output, whether tangible or intangible, that can be described in advance, created and tested

This needs to be planned and coordinated…Who, What, When, Where, How and Why.

Who will decide what tests need to be done?

Who will do the testing?

Who will gather the results?

Who will manage any necessary fixes and retests?

Who will decide if the item should be accepted or rejected?

You may want to grade the passes and fails.

Priority 1 (P1) – A complete business down situation or single critical system down with high financial impact. The client is unable to operate.

Priority 2 (P2) – A major component of the clients’ ability to operate is affected.  Some aspects of the business can continue but it’s a major problem.

Priority 3 (P3) – The clients’ core business is unaffected, but the issue is affecting efficient operation by one or more people.

Priority 4 (P4) – The issue is an inconvenience or annoying but there are clear workarounds or alternates.

Priority 5 (P5) – The issue is a background or planned task and will be addressed when time permits or on the planned date.

This grading is taken from ITIL Service Desk, but it illustrates the concept which you can tailor for your circumstances.


Here are some things to think about at project close or hand-over

  1. Support Arrangements
  2. Roles to be Transferred
  3. Key points for the Support Team(s)/ Knowledge Transfer
  4. Customer Expectation Management/ Communication
  5. Business Continuity/ Disaster Recovery
  6. Training Requirements
  7. Product List (including SLAs)
  8. Supporting documentation
  9. Security Aspects
  10. Security Officer Sign Off 
  11. Acceptance from Support Team

Since this article is principally focussed on being clear about what you want and need, and ensuring you get it I won’t go into much detail here, except to emphasise the benefit of a formal process for passing ownership, responsibility and control.

You may want to accept even with minor issues.

The solution is acceptable if ….

There are no P1 major issues

There are less than 3 significant (P2) issues, each with a plan to resolve within 20 days

There are less then 5 minor issues (P3 to P5)

This could be done by ink-on-paper signature or using a meeting and minutes to confirm arrangements and agreements.

In this article I aimed to explore how we discuss, decide, define and document what we need and ensure we get it. I hope this has been useful and welcome feedback. If you would like to discuss please get in contact.


Mentoring is to support and encourage people to manage their own learning in order that they may maximise their potential, develop their skills, improve their performance and become the person they want to be.’ Mentoring is development driven, looking not just at the professional’s current job function but beyond, taking a more holistic approach to career development.

Mentoring is non-evaluative, while coaching is based on measuring performance change. Due to the personal nature of mentoring, a mentor will more often than not draw on their personal experiences and expertise to help their mentee. This could be in the form of sharing a story that taught them a valuable lesson, or a challenge they overcame in their career. 


Tim Rogers is a Commonwealth Triathlete, World Champs and GB Rower, and now  consultant, coach, IoD mentor and mediator. His public sector work included project manager for the incorporation of the Post Office and Ports of Jersey, and project director for the Health and Social Services Governance Review. He has also supported start-ups and SMEs be successful with 4 clients subsequently winning IoD Director of the Year. He now focusses on coaching people and teams delivering change.

Tim HJ Rogers
Ex-Athlete, now Change Practitioner, ICF Coach, IoD Mentor, Mediation Practitioner 
Helping people and organisations achieve their goals.

ICF Trained Coach IoD Business Mentor, Mediator, Management Consultant, Change Practitioner Mob 447797762051

We offer #consulting, #coaching, #mentoring, #facilitation and #mediating to support individuals, teams and organisations through #change. We #consult, #cocreate and deliver #projects, #programmes, #progress and #performance using #tools, #templates and #training