Managing software projects - advice needed

Question

I work for a large government department as part of an IT team that manages and develops websites as well as stand alone web applications.

We’re running in to problems somewhere in the SDLC that don’t rear their ugly head until time and budget are starting to run out.

We try to be “Agile” (software specifications are not as thorough as possible, clients have direct access to the developers any time they want) and we are also in a reasonably peculiar position in that we are not allowed to make profit from the services we provide. We only service the divisions within our government department, and can only charge for the time and effort we actually put in to a project. So if we deliver a project that we have over-quoted on, we will only invoice for the actual time spent.

Our software specifications are not as thorough as they could be, but they always include at a minimum:

• Wireframe mockups for every form view
• A data dictionary of all field inputs
• Descriptions of any business rules that affect the system
• Descriptions of the outputs

I’m new to software management, but I’ve overseen enough software projects now to know that as soon as users start observing demos of the system, they start making a huge amount of requests like “Can we add a few more fields to this report.. can we redesign the look of this interface.. can we send an email at this part of the workflow.. can we take this button off this view.. can we make this function redirect to a different screen.. can we change some text on this screen… can we create a special account where someone can log in and get access to X… this report takes too long to run can it be optimised.. can we remove this step in the workflow… there’s got to be a better image we can put here…” etc etc etc.

Some changes are tiny and can be implemented reasonably quickly.. but there could be up to 50-100 or so of such requests during the course of the SDLC. Other change requests are what clients claim they “just assumed would be part of the system” even if not explicitly spelled out in the spec.

We are having a lot of difficulty managing this process. With no experienced software project managers in our team, we need to come up with a better way to both internally identify whether work being requested is “out of spec”, and be able to communicate this to a client in such a manner that they can understand why what they are asking for is “extra” work.

We need a way to track this work and be transparent with it.

In the spirit of Agile development where we are not spec'ing software systems in to the ground and back again before development begins, and bearing in mind that clients have access to any developer any time they want it, I am looking for some tips and pointers from experienced software project managers on how to handle this sort of "scope creep" problem, in tracking it, being transparent with it, and communicating it to clients such that they understand it.

Happy to clarify anything as needed.

I really appreciate anyone who takes the time to offer some advice.

Thanks.

Answer 1

The thing to remember is that the product originally requested is very rarely the product the customer actually wants. 80% of it will never be used and the other 20% of it will be used differently.

Changing requirements as the project goes on almost always allows the customer to end up with the product they needed, rather than the product they wanted. This is good. For you and for them.

But they do need to understand that each new requirement will cost them an old requirement (or delay the project) and they should always go through a Product Owner, who is managing both the long-term plan and the current sprint (which should not be changing unless it really has to).

Get a backlog of high-level stories and point-score them -- break these down only as they come close to the top of the pile. Also, start a burn-down chart. Put all this stuff in a place visible to the customer; if that means an electronic copy, fair enough, but if they regularly visit your office then cover the walls with whiteboards and put the info there, where everyone can see it and be driven by it.

This will serve to teach them about cause and effect. When they can see work is being checked off but the burn-down chart is not moving in the right direction, it is very easy to explain to them why. And if it isn't then it is your team who needs to question their estimates.

More often than not, such projects are driven by deadlines rather than features, so the customer can look at the features they've asked for and start thinking "hold on, this feature isn't that important, we should lose it to make sure we hit the deadline."

Finally, teach them that the sprint should be sacrosanct. Once they've requested something be delivered in this sprint, the cost of changing their mind should be greater than changing their minds about the future plan. Add a 3-point job to the current sprint and you should remove a 5-point job from it.

Answer 2

clients have direct access to the developers any time they want

That's a major problem right there. Clients should never have direct access to the developers. Developers should always be shielded from ad-hoc requests, which should be funneled through either management or lead developer (or a combination thereof).

Once the requirements are gathered by the lead/manager team (and vetted by the lead - some requests should be pushed back on, have further investigation done on them, etc etc before ever hitting the developers directly). Once the requirements are locked in, then it should be given to the developers, who are responsible for prioritizing (with help from the lead) and estimating.

Even if the developer needs to seek further details from the client at that point, (IMHO) it should still be done through a single point of contact (lead/manager) to avoid client confusion about who they're supposed to contact and when. So obviously, the more interruptions that hit a developer, the less productive they are.

I don't have the doc on hand, but it's proven that it takes at least fifteen minutes for a developer to get back in their programmer head space when any interruptions occur. It's the manager (and lead's) job to shield any absolutely required interruptions from the developers to allow them to do their job.

Once you've started shielding developers from clients, the next step is to manage client expectations better: If it's not in the spec that was signed off on (I'm hoping that your clients do sign off on them), it's not part of the project. Clients need to understand that if they want to add tasks, then others may not be completed in a given milestone. That gives them the onus of prioritizing what they want done and not done once the developers have provided a task estimate for the request.

You need to educate your clients on the impact of their request(s). Generally, once they understand how what they're asking for affects the rest of the project, you'll find that you get many less requests that aren't well thought through.

Answer 3

software specifications are not as thorough as possible

Being agile is not about not producing thorough documentation, but minimizing documentation that is wasteful. In other words, producing what you need, when you need it, in a "just good enough" form that can be evolved as the need implies. I would recommend reading Scott Ambler's article on agile documentation and make sure you are producing enough of the right kind of documentation. There are a lot of considerations that go into what documents to produce, so make sure you're accounting for the key points.

clients have direct access to the developers any time they want

This is generally a Bad Idea. The people in a developer role are paid to develop software. Some developers might have multiple roles, including a role that requires interfacing with client representatives. However, to maximize the time of everyone doing what their job is, only allow clients to talk to certain people. These people would be responsible for disseminating the information to the appropriate people on the team so that it can be acted on.

We are having a lot of difficulty managing this process. With no experienced software project managers in our team, we need to come up with a better way to both internally identify whether work being requested is “out of spec”, and be able to communicate this to a client in such a manner that they can understand why what they are asking for is “extra” work. We need a way to track this work and be transparent with it.

This is done by implementing a Change Control Board or a Change Review Board. These people are the ones who review all proposed changes, regardless of where they come from. A change could be a request from a client for a new feature, a defect report that comes from the QA/Testing team, or a task that a developer would like to do to make their job easier. The board examines each request with regards to scheduling, budget, and available resources, decides if it's a valid request, prioritizes it, and (depending on your process methodology) will assign it to a developer. If a feature is rejected or deferred, they explain why as well.

Answer 4

All the answers here have been good, just to throw in my 2 cents.

Personally I wouldn't give the customer direct access to the developers. The customer, most of the time, won't know how to get the best out of the developer and the impact that their requests will have. Someone said to me once "you can either be a shit funnel or a shit umbrella", you might not see it but you're kind of shit funnelling - the developers are the most important people in a project, not the customer, in my opinion.

Echoed here already, the customer needs to understand that development is a service based industry, they're buying hands on keyboards, not a web app.

I'd try and give an estimate, take the customers budget. Lay your projects out: kick off week, sprint week, review week, sprint week, review week etc. The more time (reviews) you can get the better - ideally I don't want developers to work more than two days a week on a project.

I aim to get the product 'launch-able' at the end of every sprint week, in the review weeks we can then work with the customer to decide what goes into the following week. If the team that are working on the project can only kick out 20 units of work in a week then there needs to be 20 units of work - if you want to add work you need to take away other work.

If the customer requests new features, book in another sprint - I normally say "if you think you're going to want it book it in now, because we might be booked with another project by the end".

I find this is easier to budget, easier to schedule and teaches the customer the impact of adding features.

Hope that's of some help.

Answer 5

It seems to me there are 2 separate issues.

1. The feature implemented isn't actually how they wanted it to be.
2. Seeing the feature they now want additional work done.

I would suggest the following:

• Make the priority list of what is being worked public

Management (your or your manager) should be how work get's prioritized. Work that is not prioritized does not get development time. Let your customer communicate with you about their work and when it will be started. I've found customers usually just want to make sure they haven't been forgotten.

• Implement sign-off on a feature-by-feature basis

We work in vertical slices at work. What this means is that when a feature is done it can be demoed in a working system. I have the developers communicate before and after starting feature work with the customer. This assures the developer has a good idea of what the customer wants, the customer can make small changes that didn't occur to them before, or didn't capture in the requirements. After the feature is implemented the developer gets sign-off so the customer gets what they want. The developers have to know how to defer the requests for additional work that doesn't belong within the scope of the feature to the appropriate manager.

• Always do mockups first

Always do the mockups first and treat that as it's own feature. Then get the customer to evaluate the mockups and sign off on them.

• Follow up

Follow up as projects (or project phases) are completed. Talked to the customers to make sure they are happy with what they got. Ask them how they liked the process used during the project. Did they get what they want, do they have any suggestions, etc.

I have found these techniques work for me pretty well.