How to deal with rapid project spec changes in a tight deadline scenario?

Question

How to deal with a project manager that imposes really tight deadlines but with a day or so before the deadline brings in new features and spec changes to implement, with another tight deadline.

The worst thing about this is that most of the new stuff leads to major rewriting of the existing code, as previously implemented business rules are no longer applicable or "gain" strange corner cases that need to be treated separately.

It seems that no matter how hard we try to make the system extensible, there always are things that come up literally in the last moment and need to be implemented and supported quickly.

How could I deal with such a situation? It's being really demoralizing and one colleague has already quit the team.

Answer 1

Don't let them impose the deadline in the first place.

You have 2 options

• The PM gives you a list of features and you tell them when it'll be ready.
• The PM gives you a list of features and a deadline. You then tell them which features you'll implement in the given time.

If the PM is your manager or has the authority to impose deadlines + number of features, then I'd be looking for a new job. careers.stackoverflow.com

If the PM isn't your manager then you need to get your manager on board and have them give the PM their options from the above list.

Answer 2

Have you and your team tried discussing about this with the manager himself? That's the first thing you should do.

He might not have that much experience with the development process, hence the constant tight deadlines and very late major changes. I've seen such cases, people who couldn't develop but thought they could do a better job at PM.
From sitting and talking to him there could come out two thing, depending on his personality/professionalism. He'd accept your points and try change the situation for the future or he'll be a smartboy and won't give in a bit, in which case it is worth escalating the situation to a higher level. I don't think there is any company that will happily accept losing developers.

Alternatively, his manager could be all over him. And that's a problem.

If nothing works out, as already suggested, changing the job is a fair thing to do.

Answer 3

This stuff is really challenging to deal with. The real problem here is that you don't actualy have a process.

The answer really depends on the political situation in your organisation and how much eneergy you have to drive change.

In the past I have attempted to introduce process change to several organisations and it has always been a struggle. It is possible, however.

I would have a look around at some methodologies for managing software development. I use and recommend Scrum, for example.

In a situation with rapid change, working on short iterations that have clearly accountable goals can be really helpful. You will probably need to champion and manage your Project Manager, but it sounds like the current "process" is clearly not working, so selling a new process actually becomes easier - you have solid business case for improvement.

A solid process will help you "push-back" on changing requirements. Rapid reactionary change is often a symptom of broader issues in organisational direction and strategy and it is in everyone's interest to fix this problem within the organisation.

Answer 4

It's true that no matter what you do, you're human and you'll make mistakes or miss things. That said, regular changes to your requirements are most often the result of either poor requirements or poor develoment process, or both.

Some Design Up Front?

Business analysis is regularly given the short shrift by developers, project managers, etc. Most devs just want to start hacking away on day 1, and most PMs love to let them: "Wow, we can move from the project initiation phase to the construction phase in 1 day without any of that ridiculous business analysis stuff taking up time! That'll look great for completion bonuses!" But remember that the PM's primary job is to keep the project under control (on time and on budget) ...not necessarily to make users happy and certainly not to make developers happy. That's not to say they are totally heartless; good PMs will achieve their goals by enforcing scope control and fostering communication, both of which are helpful.

But taking the time to really think about what's needed and stepping through possible scenarios can make a serious difference in the issues you're dealing with.

• If you have made an effort to do thorough business analysis and you're still ending up with last minute changes, then perhaps your problem is another classic challenge: disengaged users. Your subject matter experts are your top weapon in dealing with and identifying those corner cases. If you have users that are not engaged in the analysis process, get better subject matter experts.
• It's also possible users are disengaged because they are too busy doing their regular work. In that case it's a management issue and they need to be given instructions that project participation is part of their jobs; that's hard sometimes because often the same management that told you to "get it done yesterday" is the same group of knuckleheads that is expecting the project to happen magically with no hiccups and without any resources (they are common in that they don't understand the complexities of custom software development and assume it is easy). If management is clueless and won't change...well, you have to either work overtime and deal with the issues you've described, or get a new job.

Can Agile Help?

It'd sure be nice if your users would tell you about those corner cases earlier rather than later, right? This is related to what Toby Hede discussed in his post. Perhaps a methodology that gets the software in front of the users as soon as possible, even in an unpolished state, can trigger feedback sooner. That was one of the inspirations for all the agile concepts. The creators were tired of dealing with the issues you describe and they also realized that if management and users weren't going to change, then maybe the development could. It's still development, but there's an emphasis on getting early feedback through a variety of techniques (have subject matter experts co-located with the dev team, getting rough prototypes into user hands sooner, pair programming to captalize on developer experience, and lots more). All this is because it's understood we're human and we're going to miss things.

Finally, you mention you're trying to make the system extensible to help with the rapid changes, but how? Are you separating presentation logic from business logic? Are you encapsulating business logic in objects, partitioned appropriately to minimize dependencies and coupling? All of those things are tough to do and can take time to plan and build.

You're not alone, by the way. Lots (maybe all) shops have these challenges.

Answer 5

This is one of the major challenges you will face as a developer.

One good technique I've used in the past is to ask questions. When you get the specs, find something in them which needs clarification from the final users. This always slows things down, and raises the possibility in managers minds of risks.

Make sure that your project manager knows the risks involved in implementing late changes for a project.