What makes a project successful?
It’s not big, it’s not fancy and it’s almost certainly not fun but having the correct documentation and briefs will make or break your project. Sadly despite documentation being the backbone of what holds projects together and the fact it has the ability to make them (un)successful, it is something which many people get wrong.
Documentation needs to be clear and relevant to all people who will read it and kept up to date at all times. How can you expect the stakeholders, your team and also yourself to all be on the same page in regards to the why, what, how, who and when otherwise? Having the why explains to everyone the reasoning behind what is being requested, this encourages buy in from all parties. Having the what and how outlines both the expectations and requirements for the end product which enables the development team to create the desired outcome and minimises any nasty surprises for the stakeholder when the product is shipped. Having the who and when ensures that everybody remains accountable for their part in the project and in reaching it’s expected delivery date.
As all projects vary entirely in size, purpose and measurable end results, so does the documentation required. There is no set length or detail required in project briefs, however there are a few basic essential sections you need. This is how we write project briefs at my company:
- Business case: What is being asked for, who wants it and what is their justification. e.g. “The Customer Care Manager would like to implement a new chatbot system to gather information from members logged in to the website selecting ‘Contact Us’ on the FAQ’s page. The chatbot needs to have fields for members to enter their name, email address (with verification conditions) and a short question/comment which is limited to 300 characters. This information needs to be logged on the member’s record in our internal system with a date-time stamp and a copy should be sent to firstname.lastname@example.org for the customer care team to action”
- Acceptance criteria: What is the definition of done. e.g. “Have we created a chatbot system which allows for simulated two way conversations? / Does the chatbot popup open when you select ‘Contact Us’ on the website FAQ’s? / Does the chatbot provide a field for users to enter their name, email address (with conditions) and a < 300 character comment? / Do we capture the logged in member’s details from the website and log the information entered onto the member’s record in our internal system with the date-time stamp? / Is a copy of the information recorded sent to email@example.com?”
- Project timeline: Is there a deadline for the project to be complete by? If there is, ensure that this is communicated to the development team very clearly. If there is no deadline, ask those who will actually be doing the work to give you a rough idea of how long they believe it will take — this includes any investigations, development, sign-off, testing and deploy. Having a guide of how long from start of development to live shipping and use by the end user will take enables you to manage business expectations
- Risks, concerns and unknowns: Any risks or concerns which anybody has should be noted down to be considered by all involved and analysed/measured as required regardless of how big or small. e.g. “if the chatbot API goes down then the pop up won’t trigger on the ‘Contact Us’ link and members will not be able to contact us” or “the customer care team may feel like they’re being made redundant”
If all of the above has been covered, is clearly written and understood by all those involved in the project then you’re off to a good start. Now as Project Manager, you just need to ensure that this brief is kept up to date at all times. It’s all good and well having in depth documentation at the start of a project but it quickly becomes useless if requirements change or become obsolete. You should be in the habit of checking and updating the brief regularly so that everybody is able to refer back to it at any time and know what’s been asked for and is expected.
I’ve been bitten by slipping up on this just last week and it’s painful for everybody involved. I’ve learnt the hard way how having even just one slightly wrong acceptance criteria can affect a project and the people involved. I cannot emphasise enough how key it is for you as Project Manager to have requirements nailed down before getting a team to look at them and to stay on top of updating them if anything changes. However, it’s also key to have a development team who will actively check the requirements you’ve given them and raise any discrepancies or questions they have early on. If you and your team both stick to your ends of the bargain on this then you’re laughing. If you don’t, then good luck in the retrospective – you’ll need it!
If you liked this story, please share and recommend to others. There’s plenty more where this came from!