Project Requirements Brief


While you may have talked to project management mentors, taken a hard core agile approach to the weekend and come up with the living online incarnation of awesome, there comes a time when your work is judged. And a big part of that process is how you sell your project and idea to the judges.

Unfortunately, normal PR, marketing and a good sales pitch won't get you over the line here. This is GovHack, and as many will know, Government marches to the beat of it's own drum, has it's own language, and, it is no surprise, it's own measure of what is considered useful and innovative.

Below you will find a very watered down template of a one-pager that you'd usually find in Government when putting up a project for approval of Senior Executives. We've added in some explanations, and tweaked some of the headings to reflect that you are writing this AFTER you've already made something. Feel free to use this as a guide for key things to consider when you're putting your final touches to your project pages!

Chris Beer - Canberra Mentor

Title

Project Title - Every project needs one.

Contacts

Tell us who you are – names, emails


Background


What is the problem or issue? Why does a Department or Government need this? E.g.: Centrelink needs jobseekers to provide evidence that they are looking for work before they can be paid any benefits. This requirement is in Commonwealth legislation, so it has to be done.


‍Describing the High Level Business Requirements: While the rest of the world might use terms like "problem" "question" or "user need", in Government, things are framed in terms of Business Requirements. This isn't anything to do with ICT, Web or Data - this is usually the policy or operational thing which needs to be done. Business Requirements are meant to be clear and unambiguous - keep them simple and plain english. Usually they would be read by busy people who need to get key points quickly, and who probably aren't technical types at all. You shouldn't write more than a paragraph or two.‍

Objectives

Describe what your Project objectives are. Write a paragraph on what the site, app or project aims to achieve in meeting the business requirements. E.g.: Assisting both the jobseekers and Centrelinks needs in this regard, allowing for jobseekers to check-in to their online account to provide evidence of attendance at interviews or centrelink appointments.

Additional Benefits?

Are there any additional benefits which may not be immediately obvious to the judges? Eg: Provides a best practice model / framework for future similar projects.


Clients and Stakeholders

Government doesn't use the term "users" when it deals with most projects. You'll often see the term "Client", "Stakeholder" or something similar. A Client is basically the person that the project provides a solution for - while they may be a user (or an app for instance), they could also be the area that asked for the app to be built, or the area that ends up with the data that the app sends off. A Stakeholder is an area who has a vested interest or benefit in seeing the project completed. It might be other business areas in the Department who need to be consulted, it could be other Departments, or it could be the Ministers Office or even the Australian Public or a sector such as Academia, or even specific organisations. For instance, a Stakeholder for a Medicare online system is the Australian Tax Office, as it needs to know how much people pay in Health costs for calculating Tax returns. But it's also the Doctors in the field who are impacted by any changes to the system.


Internal:
  • Centrelink payment and reporting areas
  • Policy areas looking at addressing skills shortages in locations and industries
  • Internal Stakeholder n...
External:

Describe Your Approach

While they might be comfortable that you understand the need and the outcome they are seeking, funnily enough, before they give you funds and approval to go and change the world with a killer app, people like to have some sort of idea about how you intend to provide a solution to a problem. Write a paragraph or two around how you thought the above requirements and aims could be achieved. Eg: We built a mobile website that does x.

Time Frames

The cheapest and coolest app or site in the world is not good if it takes 4 years to build. Time is a resource just like any other thing. Tell us how long did the project take you (yes - bragging rights!) How long did you expect this project to take? How long do you think this project would take to turn into a fully implemented solution if someone took it the next step and into actual use?

Links to Other Projects – Govhack and others

You guessed it - no more than a couple of paragraphs or points. Solutions which have wider applications or tie into existing common solutions (such as standards based systems) are more attractive to government departments, and have a greater chance of code re-use in other projects.

Costs

Cost is just as important as quality and time to build. Government isn't just interested in the obvious cost either - licenses or the cost of a machine. Consider the "total cost of ownership" of your project in terms of it's whole life. e.g.: How much do you think this would cost to implement as a production solution – a rough single amount, but consider cost to test and finish, roll out, host, cost of staff required etc. Does your app rely on data which is updated all the time and doesn't have an API? How much will it cost to update the data manually? What happens if the data changes? Is it only iOS based? What happens when a user or agency uses something else? Will it port well, or is an Android version an entire project in itself?

Status

Where is your baby at? Choose one of: Concept, Commenced, Mock-up, Proof-of-concept, Alpha, Beta, Completed, We’ve been selling it on iTunes since midnight Friday!