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

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.