What to do About Incomplete Requirements?

Or, How to avoid the stall of a project before it has even started.

A short essay by our CEO Mark Plesko where he argues to already start developing the control system for a Big Physics project when the known requirements are still limited, or even non-existent.

It has finally happened — your new large accelerator project has been approved. After years of waiting, with the initial design papers long obsolete, the government has secured the funds. Now is the time to party! Actually, it’s the only good time to party, because it will never be as good as it is now. Once the project has started in earnest, the problems will start arriving too. And since the end of the project is never as clear, if there is an end at all, there will never be a more clearly defined moment in the lifetime of the project. Apart, maybe, from the day the minister visits the facility and presses the red button.

We, the control people, are usually still quite relaxed in the beginning phase of the project. The control system is never on the critical path, so there is no need to start early and, furthermore, we don’t have requirements yet, have we? Ah, requirements, the magic word that makes the blood of some people boil and other freeze to death. The word of both the brave and bold, who use it to demand (“give me your requirements”), and the shy and humble who use it for excuses (“we haven’t the requirements yet”).

So, what should we as controls people do? Should we rejoice with the others and start working on prototypes, technology evaluations, etc., or should we return to our dull daily business and wait for requirements to slowly trickle in? Well, it depends solely on which of the above two options we really want to happen. Requirements can be essentially a good excuse to do any of them. Unfortunately, they can be a good excuse also for others.

It is a fact that the control system group rarely gets proper and clear requirements. And when the other groups finally come knocking on our door, they behave as customers — they want already the final product, as if they were shopping products and not buying development. Knowing that this is a fact of life, what can the control group do to preempt such embarrassing situations?

The obvious solution is to just keep asking for requirements from early on. However, as it happens only too often, the obvious solution is not the best. Even in the Middle Ages, when they could still employ torture, it usually got them the wrong answers. With that option gone, there is little leverage that we have over other groups. And if we keep insisting and threatening, we just make everybody hate us, with no other tangible success.

Based on my experience, it is my opinion, although I am aware that many people may not share this opinion, to start developing the new control system even with a limited or nonexistent set of requirements. There are several good reasons:

No complex development ever follows the simple “waterfall” scenario with the phases like requirements, design and implementation following linearly one after the other only once the previous is finished. In reality, some requirements are dropped during the way, new come in, and what’s more, development cycles often follow a spiral and pass several times through all the phases. So, why not start the development with what we have at the moment? Maybe make a “straw man” design or reference implementation and use the newly gained experience in the next round of the spiral?

Technologically, it creates a sandbox to develop and test new concepts and technologies and psychologically, it creates awareness in the team and gives the junior members of the team a chance to profile themselves.

If the list of requirements is long, people often forget that requirements have different weight, different importance, and that the importance often depends not on technical considerations but on political power of the person that has provided them. Most of the politically sponsored requirements don’t have a “price tag” attached to them — they’re just somebody’s fancy. By having done a prototype, even against different requirements, we’re in a much better position to estimate the cost of implementing incoming requirements and to argue against exaggerations; or ask for a larger budget and more people.

The other use of a vertical prototype is that people can actually use it already for their work, e.g. a power supply control prototype can be used in magnetic measurements, beam instrumentation people can use the controls framework to develop their own software, and so on. Thus we make sure that people get used to the new control system early on, even though it doesn’t exactly match all future requirements.

And last but not least, there is the fun factor: wouldn’t you rather play with (call it investigate) new technologies and develop prototypes? Just don’t tell it to your boss: giving him all the other previous reason should be convincing enough.

But then you may prefer the safety of your daily chores. In that case, simply reply: “I’d like to start the new development, but we just don’t have the requirements yet”.

Related posts:

While Windows 10 is one of the most loved operating systems today, there are some issues still bothering the users. The internal Skype Microphone issue is one of such common issues faced by Windows…

Coors Banquet is promoting its brand by giving people the chance to win a fully restored 1977 Pontiac Firebird Trans Am and enough cash for a year’s worth of beer through a mobile scavenger hunt…