Should product scopes and/or project scopes be considered for small internal development work

Question

tl;dr: I work at a small company with a development team of 5-10 people, lately we have been asked to present "scope documents" for effectively all of our work before we carry out the actual work, with seemingly no regard given for the magnitude of work required.

I worry that I am often spending more time writing scope documents about small enhancements than I am actually performing the enhancement.

---

Before I explain my question better, let me establish a few baseline viewpoints on the situation.

I understand creating these documents can be considered training exercises for when the team grows larger and the current members take on lead roles. I am not against this and I think it's a valuable training experience. I just feel that the documents aren't always necessary which may lead to wasted time, being a small company it feels we are already pressed for time and resources.

I understand a product and/or project scope is absolutely necessary when beginning an endeavor on an entirely new product, I can also recognize the importance of the documents in maintaining order in a structured and distributed development team (many team members + project leader). And of course scopes are absolutely mandatory when dealing with 3rd party customers wishing to contract our development work.

I understand the need to ensure that a developer fully understands the request before engaging in work, however I am left asking myself whether or not these small enhancements, even if misunderstood, could end up taking more time than it takes to write, review, revise, and signoff the respective scope documents.

---

With the above understanding in mind, excuse the length of this post, but to describe my issues:

My questions come about in situations where our development team is applying relatively small enhancements to our own internal software. Small enhancements such as adding a single new button to a web UI that performs a simple operation, or adding a new action handler (basically 1 function) to a backend system.

These small enhancements may indirectly bring in revenue as they increase the value of our product, but we aren't directly selling these new enhancements independently. This leaves little room for any sort of scope regarding cost vs return.

All that is left is a scope detailing the expected outcome, why we're doing it, and the expected hourly work breakdown (which is often hugely over-estimated). These documents will sometimes go back and forth with discussion over small issues which could often have been applied to the enhancement after it was completed anyway, revisions will be made to the documents to reflect the decisions made in this process.

I can't help but feel like we are wasting a lot of valuable developer time writing these documents, where the minor enhancement could go through a first iteration of development in the same amount of time it takes to write the initial document. Then the time spent reviewing the document could instead be spent reviewing the code, and instead of revising the document time could be spent revising and finalizing the code -- the end result in this situation (to me) is a enhancement which took almost exactly as long as the scope/documentation phase would have taken.

My main questions being: (In the context of a small development team)

Are we taking the right approach to scoping/planning and developing?

Is there any rules of thumb that we should be following with regards to these processes?

Is there any red flags in anything above which indicates I should be looking to adjust my viewpoint on the situation?

Is there any way I can improve the situation while keeping everybody happy?

All insight would be greatly appreciated.

Answer 1

Paperwork like this is almost certainly either an attempt at delegating accountability, or an attempt at delegating responsibility, or both. Ask yourself why people are trying to pass off this responsibility, and look for ways to make them comfortable that don't require tangible artifacts like pencil and paper.

In agile teams, this would typically be done by assigning story points. Story points are an admission that developers are bad at estimation, but if you assign story points to each task as a team, over time you can calculate your team's velocity, and then your development team and management will have a better picture of how long things actually take on the clock.

Keep track of the time it takes to do paperwork. Convert that to a dollar-cost loss. This makes the price of paperwork more tangible to management, and is a concrete way of showing them (and you) how much software development effort is actually being lost. If it's really light work, do the work and then do the paperwork. This gives you the added benefit of having exact "estimates" (some of which will take less time than the actual paperwork). Ultimately, if you have actual evidence that the paperwork is costing them more money than it is providing them with benefits, they might actually forego it.

Failing all that, ask your lead to do the paperwork for you. Or find better ways to track stuff yourself. Software like Microsoft Team Foundation, nTask or Jira can help you stay on top of things.

Answer 2

The scope documents are not the point.

Someone asked for them. Someone needs them. Why?

Don't let people make you do this without telling you why. Knowing why lets you understand when you are effectively communicating what is needed verses mindlessly checking boxes in a todo list.

What decisions need to be made with this information? Is this part of how priorities will be set? Are they looking to measure if the team needs to grow? What are their real concerns?

Project management is hard. Nothing goes as predicted and not seeming to even have a plan can drive management nuts.

If this is how they're feeling you're not helping by hand wringing over the little stuff. They need to know what way the ship is headed. Not if you're swabbing the deck.

Or maybe deck swabbing has been an issue and they need to track that.

The most encouraging thing you've said is that the documents go back and forth. That's your chance to find out what mattered.

Also, bare in mind that management rarely gets this right the first time they try tracking work. Be prepared for changes. Try to enable visibility into you work. Just don't let how you're tracked manipulate how you perform.

Management will never understand everything the team does. They shouldn't have to. Don't hide details but don't drown them in them either. Represent them with high level abstractions that give them a name for a box to put them work in. Give the reason the box exists. Explain it's existence if attacked. But don't hide it.

Now sure, this is all time consuming overhead. You'd rather be coding. But if you want to get paid be sure the people that sign the checks are happy.

Answer 3

Think of each enhancement as a physical product that has to be shipped to the customer. You have some small products that you can sell for $5 and only cost $3 to produce. Unfortunately the minimum cost for each shipment is $3. If you ship these products one at a time, instead of earning $2 profit you would have a $1 loss on each item.

One solution is to create a bundle of small products that you can sell and ship in one package. Another is to hold the small product until a larger order goes out and attach the small item to the large shipment. (The Amazon “add-on item” model.)

In other words, you have two options:

1. Create a single scope document that packages several small enhancements. It may be easier to grasp the ROI when several enhancements are bundled together.
2. Slip your enhancements into the scopes of larger, related efforts.

In my experience, #2 tends to have a better chance of getting past people who are focused on the numbers and the big picture.

If I can avoid the overhead of excessive documentation, keeping product increment and team sizes small, I prefer that. Otherwise I’ve learned to accept that things are the way they are and we can improve a little bit every day.