Project Minimum Requirements

This is a statement of benefits that communicates the reason for the project, demonstrated for how it will provide value to the project customer. This statement will include who the customer is, what the customer expects in terms of functionality, how the new product will add value to the customer, and what cost benefits (ROI) will be realized.

What will “done” look like to the project customer?

Different to the Value Statement this explicitly documents when the product or service has met the requirements. This is a detailed document which describes the look, feel, and functionality of the product or service and includes aspects such as:

• Security
• Access
• Accessibility
• Features
• Data storage
• Availability
• Continuity / disaster recovery

We’ll be agreeing / allocating roles and responsibilities to all stakeholders. There is no standard list of stakeholders for each project as all projects are unique, although they may include:

• Project Manager
• Project Sponsor
• Project Customer
• Development resource
• Infrastructure resource
• Vendor / Supplier
• Partner (internal or external) – think Administration & Finance etc

See a full description of key stakeholders and responsibilities.

How much do you have to spend on the project? Has this budget been approved? Will this new product be a one-off purchase or incur a regular maintenance fee?

All projects require a deliverable date for us to work towards. When you start a project we’ll need to know what timeline you’re working towards. So we’ll need answers to these questions right at the start of the project:

• What are the key project timelines? 
• How flexible are these dates?
• Who has set the timelines; customer or other stakeholder?
• Who has influence over the dates?

We use simple “T-Shirt” sizing of S, M, L, XL which are based on a number of factors including:

• Priority
• Impact
• Visibility
• Number of resources required
• Size of budget
• Number of teams involved
• Duration of project

How would you like to be communicated to / with and how frequently? 

Some people prefer in-person meetings, some prefer reports, others slack messages etc. There is no single approach to communication, but we also accept that we can’t please everyone and so we offer a number of “standard” communication types for you to select for your project. 

These include:

• Weekly meetings
• Daily stand-ups
• Monthly reports
• Presentations
• Weekly emails
• Slack messages
• Dropbox updates
• Project Management tool notifications

Who will be the main signatories for the project? Who will sign off on the deliverable to say that the project is complete and can be closed?

This is usually performed by a number of stakeholder, but we’ll be asking you to identify who these stakeholders will be at the start of the project. 

We know that people move around in roles so it’s worth mentioning that we identify the signatory stakeholders by role and not by name.

This usually is a simple statement at the start of a project detailing simply how much risk the project customer and sponsor are willing to take. As the project is sized, scoped, and then progresses this may evolve into a complete Risk Management process.

How would you like your new product to be released to your customer? 

There are various approaches from an Agile, incremental approach; a big-bang, fanfare, released to everyone at the same time approach; to a hybrid model. 

You’ll usually know at the start of the project how you’d like to release the product and the decision on this will determine how any specific product or service is developed and will form the foundation for our allocation of resources, project sizing, and negotiation of vendor contractors. We can firm up the specifics as the project progresses through its’ lifecycle, but we do need to know at a high level at the beginning of the project.

These will evolve throughout the lifecycle of the project, but we will need to coordinate resources and so as we get within a few months of a release date we will be communicating testing plans and getting together any tech required.

No matter what the project deliverable is; the project customer will need training on how to access the service or product.

You may not know the answer to these questions at the start of the project, but as the project progresses through its’ lifecycle we’ll be assessing the stakeholder need to ensure that the customer can use the product in a way that provides value.

Products are never just handed over to the project customer without us ensuring that everything is working as planned and that the project customer is satisfied. 

We don’t expect you to have even thought about ELS planning at the start of the project, but be prepared, because we will be asking you to clarify this as the project progresses.