Best way to avoid scope creep as a developer with no project management

Question

I'm a s/w developer in a small internal IT department within a financial firm and have worked on a number of small-medium sized projects that have had little or no project management throughout. This seems to always result in scope creep and therefore not meeting deadlines and having to sacrifice good design/code to satisfy users/managers in the short term.

What can I do as a developer to ensure user requirements are nailed down before any code is written and that any change requests are properly managed, considering the demands and expectations of users/managers.

Thanks.

Answer 1

If you don't have a manager to push back when additional functionality is requested, you're going to have to do it yourself. I would publish a release schedule and add additional features to future phases of the project, so that you are not late on the entire project because of these additional features. Let people know how much time these additional features are going to add to the project and when they can expect to see them.

The hardest part is learning how to tell people NO, but it's something you'll need to learn.

Answer 2

Don't be afraid to say "NO". Politely, and professionally, of course. Don't commit to anything you no right off the bat is impossible. Don't commit immediately to anything you aren't sure of.

Also, don't be afraid to pick up a project management book, read it, and apply it, even if you're only applying it to yourself.

Answer 3

Have each requirement you receive signed off by a manager, you can manage the project yourself some-what, but have someone else approve the changes before implementing. Then you can use the sign-off as leverage to say no.

Answer 4

In this type of situation, scope creep is almost inevitable, stakeholders don't have time to help with analysis upfront and there is no formal contract. I'd recommend picking an agile methodology that allows you to constantly adjust goals and expectations. Something like scrum. The short cycles will help the stakeholders see results early and adjust requirements as they better understand the problem and they will keep you from insanity as the sprint cycle will allow you to adapt to these changes.

Answer 5

The key is documentation and visibility. We have an easy to use issue tracking system that the requirements creators use to put in their feature requests. They are never discouraged from doing so, but then meetings are spent reviewing the requests after we have swagged estimates for coding them. If there is limited time, now the requesters have to compete for coding time amongst each other, not by just expecting it to get done. We as coders are then protected from the creep since they have to discuss how it affect each other.

Answer 6

Keep track of what the current requirements are. When a customer comes and asks for new functionality, make sure that they know that adding a new feature will cause one of the following things to happen:

1. The delivery date will be moved back
2. Feature requirement will need to be dropped to make room for the new one
3. Or, their new requirement can't be met

As Bob King said in his comment, saying "no" in a professional matter isn't a bad thing.

Answer 7

Read a book about Scrum and implement the practice at your office. It effectively turns the tables on management, making them prioritize what they want to accomplish. All too often we developers are presented with a huge requirements list and a short time line. With Scrum you break those requirements down into tasks, determine how many hours you can work over a specific time, then at the beginning of that aloted time have a meeting to determine what is the priority this "sprint". There is much more too it but the real genius, asides from managing your managers is that it weeds out the "Cutesy" requirements because the priority will tend to be the real meat of the application. My life as a developer has been much more pleasant since I implemented it in my organization.

Answer 8

It's practically impossible to have a full featured specification before starting to code. Especially in small companies. An agile approach works better, but this should not keep you from finishing projects.

What you can do :

• Communicate as much possible about decisions being taken. Even of you think your boss should have done this. Preferably by email so no one can claim ignorance
• If new features are requested, make sure everyone knows how much time this is going to take. Don't underestimate. Make an educated guess and multiply the number with a risk factor, depending on the risk of the feature.
• When a project is reaching the finish line, make a list of tasks that still need to be done, together with a time estimate. Again, make sure everyone involved can see this list at all times.

Basically what you need to do is make sure everyone knows what you are doing. This doesn't necessarily make projects finish in time per se, but it serves as a miror to the managers, so they see what the consequences of their decisions are.

But all in all, communicate, communicate, communicate and become a sort of mini-project leader.

Answer 9

There are two types of scope creep. One stems from not getting good requirements up front. This results in unexpected tasks in order to deliver what's expected. If this is the problem, then you might want to take more time upfront in gathering requirements and strictly document what is expected each period. Once you have this, you can create a number of low level tasks and time estimates. If there are time overruns, then at least you will know ahead of time.

The second type stems from little features being added in the middle of the development cycle. This is where you have to learn how to say no. You can’t always say no, but you do have to pick your battles. And remember, this type of scope creep doesn’t come from one big things. It comes from a lot of small thing. It’s death by a thousand paper cutts.

Answer 10

Once you and the client are comfortable with requirements, lock them down with a signed requirements doc. Anything after that is a change request that costs more money.

This doesn't work if the client never wants to sign off. See if you can set some reasonable deadlines in your contract such as "soft reqs deadline" and "hard reqs deadline".

Obviously there should be some wiggle room and there's never a hard-and-fast way to figure out what should squeak through after the fact and what shouldn't, but adding a hard deadline and the threat of more costs will generally make sure that the vast bulk of reqs are in and immutable by a certain point, thus preserving some of your sanity.

Answer 11

Unfortunately, you'll essentially have to do the project management yourself, and learn a bit about change management. You'd be best served picking up an accessible Project Management book (not the PMBOK) and reading over any sections on change management.

On project's I've worked on, we've managed change by

1. Drafting a requirements spec which is signed off by the stakeholders
2. Estimating how much work it will take to build what's been specified
3. Each time a change is requested, estimate how much it will change the amount of work required explaining the impact to cost and completion date caused by the change
4. Say no to changes that don't include a change to the schedule
5. Get a sign-off on accepted changes (including acceptance of the change in schedule)
6. Keep a log of what changes were requested, and what was approved.

Change management in my experience is never fun, unfortunately, and there are a lot of places where things can go wrong. The most common I've heard is unrealistic expectations on estimate precision, and unreasonable demands from stakeholders (simply rejecting the implications of a change that you've spelled out, or ignoring the process with demands like "just get it done")

Answer 12

Scope Creep is all about unapproved changes. Reading your questions it looks like you know the answer, you need requirements, change requests and approvals.

If you had BAs and PMs and all the rest of the management middleware you could go the whole hog with Requirements Statements, Change Request forms, Change Review Boards etc. However i'm guessing this is not what you want.

You can do all of this simply. First up determine who the sponsor of the project is. Who kicked it off and who owns it. This needs to be one person who approves budget and scheduling for your project. The both of you need to come up with a process similar to following that you can both agree on.

Next in Excel create a sheet for your Requirements Register. List all the requirements. Give each a short description and leave a column for a longer description when necessary. Also included columns for who requested the requirement, when and if a solution is designed, and if a solution is delivered. Sit down with your sponsor and agree that this is the baseline.

Now create a Change register sheet. This needs a column for a short description, one for a longer description, a date, a column for the impact and one for the approved date and approved by. The impact column is the most important. Every time someone requests a change you need to work out how that change will effect your scope, budget or schedule. An extra feature may add 5 days and $5,000. If you need to deliver by Christmas you have to remove requirement item 1,2,3.

Once you have your requirements and a method for communicating change and the impact, the hardest part is that you can not enact a change without approval from your sponsor. This approval can be an email or whatever. But it needs to explicitly say "I approve change number 12". Without the explicit approval step you may as well not bother.

This is about the minimum amount of documentation/process you can get away with. The main goal is to make sure the impact of each change is fully communicated and accepted and rejected by the right person. This person isn't you and generally not the person making the change request.

Answer 13

Don't let features change or deepen that aren't mutually agreeable to everyone. If you have to pick, drop something else. The decisions should make themselves.

Answer 14

I have been in the same situation for many years. My experience was a little different however. Originally in my company, I was the lone wolf. The requirements meetings were all led by me. After gathering the requirements, I would build the app, and lo and behold, it wasn't what the users wanted. Rebuild time, with eleven billion changes. What a horrific process. Everyone would get mad about it from, my manager, to me, to the users.

Unfortunately I have found that people that want software, all too often, don't want to put in the time to help you design a solution that will solve the business problems they are looking for a solution to. They will be consistently vague, and not want to commit to anything.

As we grew, we hired some people to be instant project managers, even though they had never managed a software dev project before, and had little to no technical experience. This resulted in getting "concrete" specs that everyone, but me the dev, agreed upon.

Of course the results were nearly as bad as the original situation, but at least we had management buy-in on enforcing the specifications. Unfortunately these concrete specs, were filled with ridiculous, and often truly impossible wants.

After fighting for sanity in the application, it would be built. Nine times out of ten, the users were still upset, because they invariably, along with the project managers, designed stupid solutions, that did not work well for them.

Again, rebuild hell ensued.

We have now come full circle. All of the project managers are gone, and we have had some pretty heavy layoffs, so I am once again responsible for the entire cycle. Fortunately we have learned from our mistakes, and management is still dedicated to doing what is needed to enforce agreements. We also have changed a bit in the way we give the users an app.

We give them small chunks, often, and require them to test them, and sign off that the section is what they want and need. If it isn't, any changes they want get added to the end of the project, and everyone is informed about how it will change the schedule. Petty changes and whims, disappear quickly, when the bottom line is demonstrably affected.

Answer 15

You're going to have to do some project management yourself. Learn about Agile project management:

http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video

Develop a backlog and instead of saying yes/no to changes or features, sort them by priority. "Nice" stuff to make things perfect can always be deferred until later versions, and make it clear that this is what the plan is. Focus on the bare minimums to get a functional product first.