What are Your Management Priorities?

In my last post, I described 10 priorities for successful service delivery. It is a list of priorities that I find helpful when deciding where to focus my efforts. I have used it in the past to develop a five-year strategic plan. I have also used it as the outline for sole-source purchase justifications. However, you have to understand what it is and what it is not to have it be useful. The right tool for the right job is as important in management as it is in carpentry.

Despite their appearance in a numbered list, they are not a sequence of steps. You should not attempt to complete these items in order before introducing a service. If you get nothing else out of this post, get this: These are not steps for you to execute in sequence. These are priorities.

In addition, this is not a checklist. Just as it is not a list of steps for you to execute in sequence, it is also not a list of steps for you to execute in parallel. These are priorities. You do not have to complete all of these items before introducing a service.

What are Priorities? Priorities are items for you to consider when planning what to do next. They are guides when you are trying to develop guidance.

Consider the first three priorities from my list: Function, Capacity, and Reliability.

Say you are currently idle — hypothetically. You have completed all of your work. You are trying to decide what to do next. You could do anything but the institution hired you to do something. Think about your function first in deciding what to do. A jack-of-all-trades is master of none. If you focus on what you do, the institution will be better off than if you are trying to perform many unrelated functions.

Now say that you have decided to do something. Hurray! Doing something is better than doing nothing. Someone benefits where nobody benefited before. This is a start. If you had waited until you had the rest of the priorities covered, nobody would benefit now. That is interesting because, in addressing the “Function” priority first, you probably did something cheap, easy, and quick. That means you probably also addressed the “Budget,” “Parity,” and “Timeliness” priorities.

You have been doing your something for a while. Enough time has passed that you can tell the need for the function is real and you are planning what to do next. Now think about capacity. Is there enough of the function to go around? How much do you need and where do your users need it most? Is it simply a question of more, or does it have to be different? What changes do you need to make? Consider these issues and make your plans.

As you went through this stage of planning, your solution probably was not in the “cheap, easy, and quick” category any more. You had to consider its cost, and when you spend money, you thought about where you were spending the money. In considering potential solutions, you considered what other similar institutions had done before you. That means you addressed the “Budget,” “Welfare,” and “Standing” priorities.

Time passes, you implement your plans, and you now provide a useful function with enough capacity to service your intended audience. Where you focus your efforts next is on making it more reliable. The questions you ask yourself are similar to the ones you asked while increasing your capacity. Is it reliable enough? How much reliability does it need and where do users need it most? Is more enough or does it have to be different? What changes do you need to make? Consider these and make your plans.

So you see that the crux of these priorities is this: Something, More, Better. Do something. Then work on doing more. When you have enough, focus on doing better.

These priorities are a tool to help guide your thoughts as you plan what you will do next in service of the institution.

Share: Delicious | Facebook

10 Priorities for Successful Service Delivery

Several years ago, I moved from for-profit industry to academia. It has taken me a while to come to grips that profit is not a motivator here — let alone, the primary motivator. I have come to the conclusion that there are ten priorities for successful service delivery at a state-related higher education institution.

1. Function — This is really a placeholder for whatever it is you do. No matter how well or how badly you do your function, you are there for a reason. This is your primary motivator. For me, my primary function is packet transport — I do national, state, and some campus networks.
2. Capacity — Once you do something, you have to do enough of it. Whether it is producing enough handouts or having enough web servers, after basic functionality you have to have sufficient capacity. For me, that means that the network has to have enough bandwidth to carry the traffic customers produce and consume. It also means that you have the tools to know what your capacity needs are and that you use them to know when you need to increase or when you can decrease your capacity.
3. Reliability — So, you do something and you do enough of it. Now you need to be able to do it when your customers expect it. If you only have one person to hand out leaflets and they have enough leaflets, it does you no good if they are out on sick leave the day you need them handed out. You need to provide a reliable service. For me, while there are many approaches, this generally leads to discussions of redundant delivery mechanisms. Though it also involves questions of maintenance, upgrades, support, repair, and replacement and the associated staff and tools.
4. Standing — So you provide a reliable function with sufficient capacity. That is impressive. Now you can think about paying it forward. How does what you do contribute to the standing of the institution in the Higher Education community? In my case, we participate in national research and education networking organizations. We give presentations on what we have done and listen to and question others on what they have done. We provide input and seek feedback from standards bodies. We work with other institutions to solve common problems and work towards common goals and make sure that our service delivery decisions build on and support those efforts. We work cooperatively with other institutions to seek better group pricing than an individual institution could achieve.
5. Welfare — While the funding we receive from the state is a small part of our overall funding, we do care deeply about the welfare of our state. Our institution has a tremendous economic impact on the state and we see this as a specific part of our mission. Whenever possible, we try to make spending decisions in a way that benefits the state economy. Whenever possible, we try to provide our services in a way that benefits the state residents.
6. Budget — You knew we would get here eventually. We are still not a for-profit industry, but we need money to do almost any thing and that money has a finite supply. Remember though, we are not in this to make money. You have a given amount of money in your budget to provide the planned service. If you manage to be able to spend less on one part of your function you should not think of it as saving money. You should think of it as having money to do more or better. You are here to provide a function with enough capacity and reliability — trust me on this — you are probably not going to have extra cash laying around. If you do, you should use it to invest in providing a better service. If you consistently have extra cash laying around, you should reduce your planned budget in the future. There are others who need it.
7. Parity — Your service cannot discriminate on customers based on their campus location. Everyone has to have the same opportunity. That does not mean you have to build out to every potential customer, but you have to be willing to build out for the first customer that wants your service at a campus you do not currently serve.
8. Equity — If parity is about providing service, equity is about paying for service. We all have a funding model. The money that goes in our budget came from somewhere — tuition, fees, grants, or customer charges. They also come with some expectation of delivery. That means your customers expect something for their money. The problem is that you also have to account for free riders. While your service may — and probably does — expect some level of free riders, you cannot let that impact the level of service you promised by accepting the money in your budget. The old saw goes, “You cannot rob Peter to pay Paul.”
9. Transparency — Providing services in a higher education institution is rarely something you can do without help. Perhaps you rely on the service of some external membership organization that the institution is a part. Perhaps you buy part of the service from an external provider. In either case, transparency is key. While we understand that we may work with for-profit organizations, we want to understand what our budget dollars are paying for. We want visibility into the providers future plans and directions and we want the ability to influence them. The same holds for member organizations. We want some level of control in the governance of the organization.
10. Timeliness — Given everything you have done so far, this one seems hard to remember, but a service is best when it is available when needed. Unfortunately sometimes this means you have to say, “That sounds like a good idea for next year.”

Share: Delicious | Facebook

Hoping People Will Do the Right Thing

In order for a person to do the right thing, a event sequence has to occur.

1. Someone has to recognize that an action needs to occur.
2. They need to decide that they are the one that needs to make it occur.
3. They need to know what the right thing is so they can make it occur.
4. They need to know how to make the right thing occur.
5. They need to feel empowered to make the right thing occur.
6. They need to have the time to make the right thing occur.
7. They need to have sufficient internal motivation to make the right thing occur.

Now let's say we have really good people. Let's assume they were all “A” students and that nine times out of ten, they have what it takes to do the job.

With those assumptions, if we hope people will do the right thing, how often will it actually happen?

What we have here is an exercise in probability. The probability that our hypothetical worker bee will complete any event in the sequence is 0.9. The probability of completing all of the events in the sequence, and hence doing the right thing, is the product of the individual probabilities. That is 0.9 × 0.9 × 0.9 × 0.9 × 0.9 × 0.9 × 0.9 = 0.478. That means that left to her own devices, our “A” student that recognizes that something needs to be done and that she is the one to do it, knows what the right thing is and also how to do it, feels empowered and has the time and internal motivation to do it will — a little less than half the time — do the right thing.

If instead you assume that we are working with “C” students (0.7) the probability that hoping people will do the right thing only pays off 8% of the time.

So, as a management tool, hoping people will do the right thing is an exercise in futility. It is only interesting to the mathematically challenged.

Seriously, just stop it. Stop it now. Really.

Share: Delicious | Facebook

Multiverse Planning Haiku

Look at the future
See the possibilities
Choose your path forward

Share: Delicious | Facebook

Cautious Reflection About “How” We Change

As George Santayana is often quoted, “Those who cannot remember the past are condemned to repeat it.” Since I believe that is true, it is worth looking back at another, less often quoted individual — Melvin Conway. He was a programmer in the 1960s. He wrote an assembler for the Burroughs 220, he wrote a paper on coroutines, but the reason we know him at all, is that he is credited with coining Conway’s Law. Unlike other, so-called “Laws,” Conway’s Law was not intended as a joke, but rather as a valid observation of how real organizations make things.

In 1968, Conway wrote a paper called “How Do Committees Invent?” In it, he wrote:

…organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.

This is more commonly quoted as, “Any development project reflects the organizational structure that produced it.”

As we move forward in an environment of change, it is important that we keep this in mind.

To see how this manifests itself in the real world, please read this blog entry from one of the Vista programmers on how they developed a particular feature for which he was responsible. While you are reading, see if you find any of what he says familiar. If you do, consider that we may need to address those issues ourselves as we try to move forward.

Share: Delicious | Facebook

Test Planning: Test Data Sheets

When you take on a large testing project you find some interesting management issues.

• You have multiple people doing the testing and you have to be confident you know how they are testing

  • You want to know they are doing the same tests
  • You want to know how much they have tested
  • You want to have a record of what they have done
  • You want to know who did the testing

• You have multiple items you are testing and you want to be confident what you are testing

  • You want to know what model was tested
  • You want to know what version was tested

• It takes significant time to do all of this and you want to be sure when testing was done

A simple test tool that is helpful in addressing these testing issues is the test data sheet. This can be as simple as a spreadsheet or as complicated as an interactive web site.

To address the issues above, you want to have a place on your test data sheet for each of the following:

• Tester name
• Test date
• Model numbers involved in the test
• Serial numbers involved in the test
• Hardware/Firmware/Software versions involved in the test
• An identifier for the test(s) being performed
• The result of the test (Pass/Fail: Explanation)

It just sounds like paperwork, but a month after four people finish running a dozen tests on three devices in five configurations from each of nine vendors you will appreciate having that pile of paper (or bits) to refer back to.

Share: Delicious | Facebook

Test Planning: Test Verification Matrix

You can make test planning a little easier if you start with a Test Verification Matrix. This is simply a table that lists each requirement and the method that you have decided to use to verify the requirement.

Suppose the requirements I used as examples in my previous post were the only ones we had. In that case, the verification matrix would look like this:

Test Verification Matrix

Requirement	Verification Method
PC2. Port connectors provided on the front panel	Inspection
AE1. Provides at least 32 10/100/1000BASE-T ports	Inspection
EN1. Operates in temperatures between 32 and 104°F	Inspection
CM5. Manageable locally using console access	Demonstration
IO1. Passes IPv4 unicast packets at full line rate	Test
ZZ1. Provides an average jitter of less than 10 milliseconds.	Analysis

This can be useful because you can frequently verify requirements that have the same method at the same time. For instance, in your test plan you might group all of your inspection requirements together and perform them as you unpacked the item to test.

Share: Delicious | Facebook

Classical Requirements Verification Methods

Back in August, I started introducing Program Management with an introduction to the System Development Life Cycle. I have talked in more detail about some of the early phases of the life cycle, like Operational Concept Development and System Requirements Specification, but right now I would like to skip ahead to the Test phase.

We are at a point in our basic switch replacement process when we have to start planning to test the candidates that have made it through our paper evaluation.

In this part of the process, we need to verify that the devices we are considering actually meet our stated requirements. I will provide a future post on the testing process, but before I do it is good to have an understanding of the four classical requirements verification methods:

• Inspection
• Demonstration
• Test
• Analysis

Inspection

Inspection is observation using one or more of the five senses, simple physical manipulation, and mechanical and electrical gauging and measurement to verify that the item conforms to its specified requirements.

For instance, we have this requirement on the physical characteristics of our basic switch:

PC2. Port connectors provided on the front panel

We will verify this requirement through inspection. That is, we will look at the switch and observe where the port connectors are located.

In fact, we will verify many of our requirements through inspection. All of the requirements indicating port types and counts, like:

AE1. Provides at least 32 10/100/1000BASE-T ports

In addition, for anything that is beyond our capabilities to test, we must rely on vendor documentation. We also considered these inspection methods. For instance:

EN1. Operates in temperatures between 32 and 104°F

Some companies would put the item in a temperature chamber and cycle the temperature while conducting performance tests. We do not have that capability. We will satisfy ourselves with an inspection of the vendor documentation as to their reported operating temperature range to determine whether the units satisfy these requirements.

Demonstration

Demonstration is the actual operation of an item to provide evidence that it accomplishes the required functions under specific scenarios.

Consider this requirement:

CM5. Manageable locally using console access

We will plug a local console device into the item and demonstrate that we can use it to perform a sampling of management functions.

Test

Test is the application of scientific principles and procedures to determine the properties or functional capabilities of items.

Test is similar to demonstration, but is more exacting, generally requiring specialized test equipment, configuration, data, and procedure in order to verify that the item satisfies the requirement.

Consider this requirement:

IO1. Passes IPv4 unicast packets at full line rate

We will verify this requirement by testing. We will use specialized test equipment (SmartBits Data Sheet) we will connect it to the item in a particular way, configure the control software just so, and run specific data through it according to a repeatable procedure from which we will get a binary result indicating whether the item did, or did not satisfy the requirement.

Analysis

Analysis is the use of established technical or mathematical models or simulations, algorithms, or other scientific principles and procedures to provide evidence that the item meets its stated requirements.

As test was like a more involved version of demonstration, so analysis is like testing on steroids. In analysis, many tests may be performed, but the results of any given test do not give a pass or fail indication, rather all of the results must be taken in concert and we must perform some further operation in order to determine whether the item satisfies the requirement.

Let me say that I do not believe we have any requirements that require analysis in this case. After all, this is the basic switch. However, if we had a requirement like this:

ZZ1. Provides an average jitter of less than 10 milliseconds.

In this case, we would have to verify this requirement using analysis. We would perform many tests, collect the resulting data, measure the time between output packets, and then calculate the average. We might repeat this many times over a 24-hour period and show whether the average jitter ever went above 10 milliseconds.

Share: Delicious | Facebook

Other Clarifications

I have been putting together some posts on program management and system development. One of the upcoming ones will be how to write well-formed requirements. As an example of why well-formed requirements are important, I would like to share some issues with a recent piece of my own work: the Basic Ethernet Switch Replacement Requirements.

IEEE Std 1233 defines a well-formed requirement as “a statement of system functionality (a capability) that can be validated, that must be met or possessed by a system to solve a customer problem or to achieve a customer objective, and that is qualified by measurable conditions and bounded by constraints.” Later it describes the properties of a requirement. They should be implementation independent. You should state them so they have only one interpretation. They should be traceable to a specific need. There should be a way to prove that the system satisfies them.

To break that down, each requirement:

• can be validated

• must be met (or possessed) to solve the problem

• is measurable

• is bounded by constraints

• is implementation independent

• has only one interpretation

• is traceable to a specific need

• can be proven to be met

With that in mind, look at some of my requirements.

AS3. Does not require the use of proprietary mechanisms, where an IEEE, IETF, or Internet RFC standards based mechanism is currently available

This sounds like a great requirement. Do you want ice cream with your motherhood and apple pie? It would be a wonderful world if everybody did everything in a standard way. On the other hand, it might stifle innovation. When it comes down to it, if we have specific traceable needs for things to be done in a standard way, we should ask specifically about them. In fact, we do regarding CDP, LLDP, LLDP-MED, CIP, and IEEE 802.3af. As for this requirement, we cannot validate it, it is not necessary to solve our problem, and it is unbounded. Worst of all, it has more than one interpretation. Is “Yes” or “No” the correct answer? (“Yes, we only use standard mechanisms,” or “No, we do not require any non-standard mechanisms.”) This is especially troublesome when you state a requirement in a negative way (“Does not do X.”)

For the purposes of the basic switch, I will strike this requirement. For future documents, I will keep it as a note to the writer that if a system can acceptably satisfy a specific need in a standard way, we should ask the system to do it in that way.

MN7. Propagates framing errors to the mirror port

MN10. Alerts the monitoring port or log record if mirror packets are dropped

These two requirements are troublesome because they are interdependent. The idea is that if you are monitoring traffic on a mirror port, you want to see everything. If there are errors in the traffic, you might want to see that, as well. Hence, MN7. However, you might consider this to be an error, which is acceptable, in which case we would at least like to know that you did not forward the error traffic by having you log the fact. So, if you answered MN7 and MN10 “Yes” and “No,” respectively, that would be OK. If you answered “No” and “Yes,” that might still be OK. If you answered “No” and “No,” that sounds bad. If you answered “Yes” and “Yes,” you clearly did not understand the question.

If you go back to the list above as to the properties of a well-formed requirement, you see that the problem with each of these is that individually the system does not need to meet them in order to solve the problem.

For the purposes of the basic switch, I am going to ignore responses to these requirements. We will still test to be sure the equipment does what we need. In the future, I will try to find a way to express our need more clearly.

SC1. Does not forward unicast packets not destined for an individual port

SC2. Does not forward packets to a port before learning the MAC address of the attached device

The basic switch has had a long life at Penn State — longer than many of the applicable standards. Today, the operation of a switch is well defined in IEEE Std 802.1D-2004.

For the purposes of the basic switch, I am going to ignore responses to these requirements. We will still test to be sure the equipment does what we need. In the future, I will try to find a way to express our need more clearly.

SC4. Can continue to operate when ports are placed in the loopback condition (pin 1 to pin 3 and pin 2 to pin 6)

I believe this requirement arose when devious individuals learned that shorting the indicated pins creates, in some very old devices, a condition where the switch sends itself a BPDU and then receives it on the same port and then spends all of its remaining time on this Earth forwarding the packet around at the expense of forwarding actual traffic. Eventually the IEEE modified the Spanning Tree Protocol to validate a received BPDU to be sure the same port that received it did not transmit it (Clause 9, section 9.3.4, Note 1). This is an obscure requirement and not normally listed in data sheets, though we expect most modern devices satisfy this requirement.

For the purposes of the basic switch, I am going to ignore responses to these requirements. We will still test to be sure the equipment does what we need. In the future, I will try to find a way to express our need more clearly.

Summary

I know some people think spending time creating well-formed requirements is time wasted. If I had spent more time up front, I might have been able to reduce the amount of hands on testing my group will now have to do. That is the trade off: more time now for less time later. I have heard it said this way: “Fail early, fail often.” Be like Gordon the Guided Missile.

Share: Delicious | Facebook

What is a PM?

Different people call them different things — product managers, program managers, and project managers — depending on their culture, organizational structure, and the type of work their group performs. However, they all count as P.M. to me. Here is one perspective on their work from the New York Times technology editor, David Pogue:

When I’m reviewing something for my Times column, the first line of defense for the company whose product I’m trying out is usually the P.R. person. Often, though, I’m then put through to the person who really has the answers: the product manager.

The product manager (P.M.) is an interesting beast, sort of a crossbreed: somebody who knows a lot about the product and its target audience, as the engineers and programmers do, but who’s also there to promote the product, as the P.R. people do. (Just as the P.R. person is a gatekeeper for the P.M., the P.M. is a gatekeeper for the engineers if the questions get too tough.)”

References

David Pogue, ‘Amusing Tales of Product Managers’, The New York Times (September 6, 2007) <http://www.nytimes.com/2007/09/06/technology/circuits/06pogue-email.html> [accessed September 6, 2007] (para 1–2)

Share: Delicious | Facebook

Intro to PM: System Requirements Specification, Part I: Definitions

What is a system? A system is an interdependent group of people, objects, or procedures constituted to achieve a defined objective or some operational role by performing specified functions.¹

What is a requirement? A requirement is something a system must do. It is a condition or capability a user needs in order to solve a problem or achieve an objective.

What is system requirement specification? It is a process that produces a set of requirements that, when realized, will satisfy an expressed need. It provides a description of what a system’s customers expect it to do for them. It is a way of converting raw customer requirements into well-formed and organized ones. It is a method to provide a “black-box” description of what a system should do, in terms of its interactions or interfaces with its external environment.

What does the environment of a system include? A system’s environment includes all of the things that influence the system. These fall into categories like:

• Political
• Market
• Industry Standards
• Internal Policies
• Cultural
• Organizational
• Physical

Does system requirements specification show how to build the system? No. System requirement specification does not result in a set of instructions. We use it to ensure communication between the technical community and agreement on what the system must do to achieve its goals. During design and development, we use it to determine the requirements of the various parts we determine the system must have. We use it to develop test plans. We use it to verify the system operation when we believe we are done.

References

1. Software Engineering Standards Committee of the IEEE Computer Society, ‘IEEE Guide for Developing System Requirements Specifications’, IEEE Std 1233 (1998) <http://ieeexplore.ieee.org/iel4/5982/16016/00741940.pdf> [accessed Tuesday, August 23, 2007] ↩

Share: Delicious | Facebook

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

Introduction to Program Management: The System Development Life Cycle

There are many theories on how best to manage the development of a system. Many revolve around the idea of a system development life cycle. The analogy being that a system is conceived, is born, grows up, gets a job, and eventually dies.

There are more formulations of the system development life cycle than there are chili recipes. However, they all share a common set of activities.

I break the activities down as follows:

• Inception — Some people call this a “kick off.” I used to call it “initiation,” until somebody pointed out to me that at an institute of higher learning with an active Greek community, that term has other connotations. Regardless of what you call it, it starts with the moment when a business need or opportunity is identified, documented, approved, and a champion is appointed to pursue it.

• Operational Concept Development — This activity gives the customer an opportunity to describe and document their need without getting mired in technicalities that can be dealt with later. This is where you’ll see flowery terms like “reliable” or “easy to use.” You might also see suggestions for ways to implement the solution, but these are only suggestions. Use them to explore concerns about solution strategies, looking for design constraints. In a case where the effort is a modification to an existing system, this is an opportunity to make up for poor existing documentation and establish a baseline for it.

• Program Management (PM) Planning — Once you have a good idea what the need is, you have to think about how it impacts what you are already doing in terms of development. Does it fit with your group’s objectives? When is it needed? Is there sufficient manpower available to adequately address the expected activity? Does the group have the necessary technical resources? Does it have the necessary skill set?

• Analysis — System Requirements Specification — In this activity you identify the raw “black box” requirements — interface, functional, data, performance, security, maintainability, and so on — and from them you build “well-formed” requirements that describe capabilities the system should have and the conditions and constraints that apply to them. At the end of the activity you should be able to present an organized set of requirements that if implemented, should satisfy the identified need.

• Design (not what you think it is) — In the design activity, you look inside the black box for the first time. You come up with a plan to implement the requirements. You identify and document the components inside the box, how they interconnect, and what each has to do.

• Development — Once you know what you need inside the box, you need to figure out how you are going to provide each of those components. You’ll decide which components you are going to build and that you’ll buy, and then you’ll build and buy. At the end of this activity you should have a bunch of components ready to put together for the first time.

• Integration and Test — This is where you roll up your sleeves and put it all together, make it work, and show that it meets its requirements.

• Implementation — Once you have shown your system meets its requirements you can build as many as you need.

• Operations and Maintenance — Working systems almost always need to be watched and occasionally nudged to keep them working. This is where you do that.

• Evaluation — We would all like to think we get everything right the first time, but that never actually happens. While a system is in operation, you should evaluate whether and how it addresses the real needs of its users. If there are shortcomings, you should consider starting on a revision of, or a replacement for the system.

• Disposition — All good things come to an end. Eventually the business need will go away, or be solved in a different way that makes the system obsolete. This is where you clean up the flotsam and jetsam of the life cycle.

Update: Typically a Manufacturing phase would follow Development and precede Integration and Test. However, I believe it unlikely that anyone at Penn State will do any manufacturing as part of a system development, so I have ignored it for the purposes of this discussion.

Share: Delicious | Facebook