Introduction to Program Management: Operational Concept Development

Operational Concept Development is one of the earliest steps of system development. Whether it is a new system, or an existing one that you are thinking of modifying, there are certain things that you need to know before you get too far. In fact, the simple act of asking the questions can sometimes solve the problem. So sit down, talk with your customer, and talk about the system — “it” — until you can say you know the answers to these questions.¹

A picture is worth a thousand words, and while it might take many words to answer these questions, it really might only take a few words and a some well drawn pictures.

It is good for you to know the answers to these questions, but if you write them down, you can share them with others and refer back to them as the project progresses.

1. What is it called? We need to be able to talk about the system. We work on a lot of systems. In order to know that we are talking about this one, we need a unique, memorable name.

2. What is its purpose? This is the proverbial 10,000-foot view. We are really looking for an elevator statement here.

3. What documentation about it exists? If the customer has already given the subject some thought, you owe it to them to do your homework and not waste their time regurgitating information that already exists.

4. What is its history? If the system is new, how did the idea for it arise? If it already exists, why do we have the system? When did we get it? Has it changed before? If so, why did it change before? Is the system ingrained in the culture or politics of some organization?

5. Who are the stakeholders? Identify the developers, operators, maintainers, managers, payers, users, and so on.

6. Where is it? Or, if it is a new system, where do we want it to be?

7. What are the characteristics of its operational environment? The circumstances, objects, and conditions surrounding it. Technical, political, commercial, cultural, organizational, and physical influences as well as standards and policies that govern what a system must do or how it will do it. Identify facilities, equipment, hardware, software, personnel, and procedures used with it. Be as detailed as necessary to give an understanding of the numbers, versions, capacity, and so on, of the operational environment.

8. What are its external interfaces? It must get inputs from somewhere and provide outputs to somewhere. What are they and what do they look like?

9. What functional capabilities does it have? What can you do with it?

10. What performance capabilities does it have? Speed, throughput, volume, frequency, and so on.

11. When is it used? Describe the scenarios under which a user would decide to use the system.

12. What procedures are involved in making it work? Even an autonomous system interacts with people at some point. Procedures involve interacting with people. What are they?

13. What are its major components? If it is a new system, you will want to take the answer to this question with a grain of salt. It may be convenient for the customer to explain their concept as the interaction of certain parts, but ultimately what is important is whether the system does what it should, not whether it has certain components inside. Leave defining the internal behavior — the interaction of the components — of a new system should until design time.

14. How do its components interconnect? As with the major components, for a new system, this is only a communications aid.

15. How is it supported? Some systems are vendor supported, dedicated staff supports others, and some have no support at all. Unsupported systems are actually user supported, since they are the ones that have to make it work when it breaks. The system support model will place constraints on your implementation.

16. What has happened that we want to change it? Whether it is a new system or an existing one, some trigger event resulted in the identification of the need for the system or the change. What was that trigger?

17. What changes do we want to make to it? For an existing system, you have just gotten an idea of what it encompasses. At this point, you picture either a working system or a broken one. If it is broken, you are going to talk about changing it. If it is working, you are going to talk about adding to it.

18. Which changes to it are essential? Any time you talk with the customer you should let them fully express themselves about what they are thinking. However, you need to be clear on which things are essential and which are not.

19. Which changes to it are desirable? Just below essential changes are ones that are desirable.

20. What is the priority ranking of the changes to it that are desirable? If there is more than one desirable change, you will need to know which is higher priority so you will know where to concentrate your efforts.

21. Which changes to it are optional? Ranking below desirable changes are optional changes.

22. What is the priority ranking of the changes to it that are optional? If there is more than one optional change, you will need to know which is higher priority so you will know where to concentrate your efforts.

23. What changes to it have already been considered and dismissed and why were they dismissed? In order to understand how to move ahead it is sometimes helpful to understand the logic behind what the customer may have already looked at and decided not to do.

24. What assumed constraints are involved in the changes to it? If the customer is aware of preexisting constraints — performance, physical, political, cultural, schedule — you had best know what they are up front.

25. How do the answers to questions 7–15 change because of the changes to it? Assuming the system already exists, whatever changes you make to the system itself may have an impact outside the system in terms of new external interfaces, new support mechanisms, and so on.

26. How do the changes to it address the reason, given in answer to question 16, for wanting the changes? This is a sanity check. If you get this far and you cannot explain how the suggested changes address the identified need then you need to have a serious chat with your customer. Better to have that chat now than after months of development and dollars spent on a system that does not address the need.

27. What disadvantages or limitations does it have after the change? Now that you have a sanity check, this gives you a reality check. All systems are limited. It is best to understand those limitations going in, rather than being surprised by them at then end.

References

1. Software Engineering Standards Committee of the IEEE Computer Society, ‘IEEE Guide for Information Technology — System Definition — Concept of Operations (ConOps) Document’, IEEE Std 1362 (1998) <http://ieeexplore.ieee.org/iel4/6166/16486/00761853.pdf> [accessed Tuesday, August 21, 2007] ↩

Share: Delicious | Facebook