Project Management

3 Benefits of Documenting Project Requirements

From the The Money Files Blog
by
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from GirlsGuideToPM.com.

About this Blog

RSS

Recent Posts

What is Expected Monetary Value?

What are sunk costs? [Video]

3 Benefits of Documenting Project Requirements

5 Tips for Exam Success

3 Options for Dealing with Team Conflict


Categories: requirements


documenting requirements

I think it’s important to understand project requirements.

I get that people want to be flexible and work things out as they go. But if you don’t know where you are going, how do you know if you’re on the right track?

It doesn’t matter to me how those requirements are documented. You can write user stories, or put together a waterfall-inspired requirements traceability matrix.

The important thing is that they are documented. The journey you’re on needs a destination.

Of course that destination might change. That’s what change control is for, or backlog grooming. You pick and choose as you go, being flexible and making alterations that mean you constantly add value. But at least there is some goal.

I’m thinking particularly of a project team that thankfully I wasn’t part of, but I know it was very frustrating for the project manager. Their role changed from being a ‘proper’ project manager to being someone who oversaw a team doing lots of small ad hoc developments and changes that felt very much like BAU enhancements, with no end in sight.

He needed to get out of that project, because effectively what had happened was he’d morphed into the role of product owner and the project had drifted into being a live service, without a formal close down and handover.

And I’ve been on projects where there hasn’t been anyone to handover to, so I’ve had to keep the support elements until someone could be made available. That is not fun.

 So if your project stakeholders are more inclined towards drifting to the finish line than working out the map to deliver their vision, then here are 3 benefits of documenting requirements to share with them.

1. A winding journey is a slow one

Do they want to get to the destination quickly or not? Perhaps slow is the correct approach. But in my experience businesses want fast results, with the least amount of money and resource time spent on getting there.

You can’t do that if you are constantly fire-fighting, dealing with changes, doing rework and coping with the misunderstandings and lack of clarity that come from not knowing what you are doing.

2. Better requirements = Better cost management

The same people who are reluctant to help you prioritise what should really be in scope could easily be the same people telling you to do the project cheaply and to keep an eye on cost.

If you know what’s in scope, you can budget better. The more stable your requirements – or at least the end goal – the easier it is to work out what it’s going to cost to get there, and how much you are prepared for that figure to be.

3. Documentation helps formalise the project

Is it really a project, or is it a piece of BAU continuous improvement?

If it’s truly a project, you should know it has a start, a middle and an end. You might not know exactly how you are going to get there. You might manage the work in different ways, with different methodologies or approaches. But ultimately, you know it’s going to finish.

Without documentation, it’s not clear to me whether it’s a real project. If you can’t articulate what you are doing, and your sponsor isn’t prepared to put it in writing, then that’s a red flag for me.

You can still put things in writing, however informally, and caveat them with saying things might all look different once the work starts or whatever. But having documentation increases engagement and makes the project work more formal. Which in turn makes it easier to get resources to commit to doing tasks.

Posted on: April 21, 2020 10:56 AM | Permalink

Comments (4)

Please login or join to subscribe to this item
Very interesting article, thanks for sharing

Thanks for information and posting!

Sometimes it looks like everything is going very fast and activities such as writing together a document for requirements, writing a test case document seems very time consuming. It looks like there is a lot of clarity in what has to be developed. However without having a vision that is pinned to something and the whole team moving towards the pinned goal, chaos will start creeping in. And when this realization occurs, things would have gone totally out of control. So it is very important for the project manager to highlight these risks to different stake holders, in different forums and try different means of explaining the impact. And senior management plays a key role too in these situations. One good practice I have seen in my experience was senior management doing “Skip Level Meetings” on a periodic basis on the teams. Here the people right above (in the hierarchy) the project manager will be skipped and meeting will be held with the project manager and the senior level management. This gives an opportunity to the project manager to voice his/her opinions freely.
Sometimes the account manager or client relationship manager has to get involved to put in a word with the client manager about the troubled waters that project will get into, if they continue to execute the project without requirements clearly laid out.
Maybe its time to read the Hare and Tortoise story again !

Good one (as always). Sometimes is challenging to have the team members documenting and/or supporting that activity, this 3 key point will help me to explain to the team.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"I am not young enough to know everything."

- Oscar Wilde

ADVERTISEMENT

Sponsors