Improving the Requirements Development Process

Replies to This Discussion

Permalink Reply by JOHN SCOTT on May 27, 2009 at 9:53pm

the more time we waste on developing 'better' requirements is time that could be spent on software code. At most you've got 6 months before all the assumptions we make in the process are aver taken by new hardware, software languages, etc.
We need to get away from treating acquisitions of IT systems like buying a tank or a TV. These systems are never done and continually dynamically evolving

Better to hire a good cadre of developers to build, extend and evolve systems vs. thinking it will be delivered at the end of a long and tortured process.

also better to fail on a small scale faster, than one big large failure at the end.

Permalink Reply by Gwynne Kostin on May 27, 2009 at 10:27pm

Oh boy, John said just what I was going to say! The problem isn't better requirements. We just never know what we don't know.

The most successful projects I have been on have had crystal clear goals and endstate and a RAD process--or some level of incrementalism--to create a successful product.

And John nails it, too, regarding having resources on hand to create, nudge and remake systems. This is Kundra's goal, too. Let's roll up some sleeves and make it so.

Permalink Reply by Dick Field on May 28, 2009 at 10:50am

"also better to fail on a small scale faster, than one big large failure at the end."

Hmm, sounds like somebody's been reading Dan Ward!

Permalink Reply by Felton Jones on May 27, 2009 at 10:30pm

John,

That is an interesting and insightful comment. Are you saying that technology moves so quickly that we have no time to develop requirements? Even when acquiring tanks and TVs the IT componnents are so critical that your comment would apply..

I am not sure I agree with the notion of "hiring" (do we mean contracting?) with a set of software developers. That seems very expensve and leaderless. I would prefer to rely on an in-house cadre of system engineers to attempt to define requirements and perhaps to try to project the future state.

In pursuit of that goal, I believe the topic turns on the best approach to enlist expertise from industry.

Permalink Reply by Kim Patrick Kobza on May 27, 2009 at 11:09pm

This is a key point and again, admitting my bias, requirements development (which is basically innovation and design) could be a collaborative and open process. This would provide the government with best of breed and innovative ideas and level the playing field. Also, a key point is that the best solutions are most often the combination of multiple memes building on themselves - not merely one idea. Why not enlist the assets of citizen, academic, and vendor networks to assist in idea generation and technical writing? Perfect area for social collaboration.

For some, but maybe not all requirements, social collaboration also provides the ability to reach into not simply the vendor community, but academia and pools of skilled retirees. One of the statistics that is relevant to the use of social collaboration in scope and definitional processes is this metric: 9 out of 10 new products fail. What if we reduced the failure rate by 10%? Even small reductions in failure rates often result in an increase in internal rate of return of up to 20%, Social collaboration properly applied can do that.

The other benefit of social collaboration in scoping - especially in government is compression of cycle times. This is important because technology especially has a limited useful life-cycle - often less than 24 months. For long scoping cycles government designs lead to functional obsolescence, simply as a function of time required in systems design and then implementation. We end up trying to solve today's problems with yesterday's state of the art solutions.

Functional obsolescence is most pronounced in communications technologies, although, it could be argued that it also exists in transactional systems. Standardization of rules across government would solve a great deal of this. But also, reordering unstructured communications structures to position them at early stages of design and decision making processes would go a long way towards early issue identification and collaborative solutions - all guided by program managers.

On a competitive level, an open process would level the playing field. Today, individual vendors essentially make their case, roll those ideas into an RFP/RFQ and predispose awards. You might find that a more open process would surface the small innovative and emerging companies willing to compete on the basis of ideas. The larger more centralized companies that often rely on their ability to aggregate assets to navigate myriad rules, and access to government officials, would have to compete on the basis of value added. This would have a secondary benefit of dramatically lessening transactions costs to government that are characteristic of highly complex processes.

Government should reward those capable of solving complex problems with simple solutions rather than those who take simple problems and make them complex.

On methodology of participation, there are many types of network services that will be appropriate for different types of business problems inherent in the process. Wikis might be appropriate to chronicle institutional memory for a design process, but 2 or 3 phased processes for structured communications and social collaboration might be better in for instance, a process that is built on alternative analysis. Those have different needs.

There are positives and negatives to each. Idea submission can also be closed if need be with submissions treated as confidential.
The key policy and practical question is whether gov would like to use its networks to provide accreditation and relevancy assessments to different possible solutions. Forward thinkers, like Yochai Benkler, Wealth of Networks, ascribe to this view and see public involvement in review and accreditation as a social good. Again, comes back to a policy decision in each case.

The other obvious benefit to program managers is free learning and education. This probably could work in both directions. The possibility of openness in design, scope and requirements is truly transformative.

Permalink Reply by Mary Davie on June 11, 2009 at 8:11am

Kim, I believe your statement "Wikis might be appropriate to chronicle institutional memory for a design process, but 2 or 3 phased processes for structured communications and social collaboration might be better in for instance, a process that is built on alternative analysis" is key. I was speaking with someone last night who is with a company that is transitioning from being a small business to a large business. We were discussing the concept of collaborative, open requirements development and he pointed out that as a small business, resources are very limited requiring the company to make calculated choices about what work they bid on with those limited resources in contrast to larger companies who can bid on more work and spend much more money on each of those bids.

He applied this line of thinking to the concept of using an open development wikified platform for requirements development. He believed it would be hard for a small business to "keep up" with and respond to the ideas flying around in the cyberspace environment and felt again, that large businesses could have teams of people researching, generating ideas and responding to others' ideas that would (or could) sway the requirements development process and potentially steer the resulting requirements document in the favor of those with most resources to throw at it. We both agreed the Long Tail would probably apply well in this situation which would mean we'd have to understand the underlying relationships of the factors that would impact the parity in the process.

I also believe there is great value in some of the traditional forms of communication we often use in conducting market research and developing requirements and that an online collaborative approach would not necessarily replace those other channels but could be used in addition to, for complementing and augmenting traditional processes while adding transparency. So your idea of "2 or 3 phased processes for structured communications" might be an approach to help level the playing field.

Permalink Reply by Kim Patrick Kobza on June 21, 2009 at 7:04pm

Mary, One of the thoughts that is fascinating about your comment is the likely tension between the centralized, institutional, vendors and the small business long tail vendors. Could the institutional vendors "overwhelm" the process?

The ultimate goal of any Gov2 strategy should in large part be to achieve the best result, and most options for the government and its stakeholders. Generally speaking gov 2 tools are viewed as a low cost way to enable the long tail - small businesses. Theoretically, they should be able to touch a greater subset of a limited population of opportunities. They should also be able to advance more possible solutions for government - the quality of ideas rising to the top. But that can only happen if all ideas start on an equal footing.

We might say that today large vendors that aggregate resources have advantages. And undoubtedly smaller vendors also have advantages in many others - especially where highly specialized knowledge is required. Gov 2 or in this case acquisition 2 could and maybe should shuffle the deck in ways that we can not anticipate.

Chances are good that application of 2.0 to acquisition much as in the private sector will generate emergent properties that we do not expect. And to complicate our decision making, it might take a while for us to be good at it, or to fully understand how to best leverage.

Chances are good that we aren't going to get acquisition 2 exactly right, at inception. But the alternative is status quo and we have seen in private sector transformations that stasis is not a viable option.

Permalink Reply by Peter G. Tuttle on May 28, 2009 at 8:14am

I think industry would be reluctant to provide meaningful requirements input in a public forum without some degree of anonymity. I've been involved in too way many open forums where industry says virtually nothing (industry days, pre-solicitation conferences, RFI's) because of competitive concerns. The goal for the companies I've worked for has always been to get in and see the government in a face-to-face meeting to discuss or "shape" the requirements.

Although I understand and agree with industry's rationale for caution, I do see constrained communications as a barrier to an effective requirements formulation process.

Can we have more dialog on John's and Gwynne's points? I agree that the requirements development process can be convoluted and agonizing, but we've also all seen situations where the process is "streamlined" to the point where requirements are ambiguous and non-reflective of what the government is actually trying to achieve. Where do we draw the line? Obviously, the government needs to communicate its needs in a manner that they are understood by industry.

Permalink Reply by Devin B. Hedge on May 28, 2009 at 10:34am

Has anyone here read up on Agile Management and Agile Software Development processes? Basically, one of the first principles is that the only constant is change; specifically, changing technology and requirements. This was illustrated in "The Mythical Man Month"in 1975, in "Death March", "Facts and Fallacies of Software Engineering (Agile Software Development)", "Rapid Development: Taming Wild Software Schedules", and on and on.

We often confuse capabilities with requirements, and requirements with user expectations. I've rarely seen changes in what capabilities the government is asked/legislatively required to deliver. I do see changes in the requirements from one administration to another, thus necessitating changes to the system and software requirements. I do see changes in user expectations with EVERY iteration of a requirements document. Why? Because we have a lot of bright people in the country and are thinking up new and better ways to do things.

Here is the rub: the Federal Acquisition Lifecycle doesn't allow for this level of innovation. Technology is moving at an exponentially increasing rate faster than Moore's Law. Remember, Moore's Law only applies to hardware. Software in turn, has not progressed at the same rate as hardware as evidenced by the fact that most computers have more processing capabilities than software using the processors. (Refer to VMWare and Forrester Research's hardware utilization survey from 2006). Software has lagged behind hardware largely because it takes time to create and people are still figuring out how to use the tools: people are what's holding software back. This is changing rapidly as we see the generational shift in the workforce. As each generation enters/exits the workforce the barriers to software creation drop and new ways to do things are found. (Reference the US Dept. of Labor Statistics via YouTube's "Shift Happens") Bluntly, the rate of change is mind numbing, and it has very little to do with software or technology directly, but more the adoption and utilization of technology through a shift in demographics and world economics.

Bringing it back down to Earth: The Federal Aquisition Lifecycle is no longer aligned with reality for software and systems implementation.

Example: during one "requirements" development phase for an RFP with one government client, we utilized the SCRUM Agile Development Methodology and Open Source development tools to iteratively build a proof-of-concept that demonstrated how the requirements would be implemented. This occurred over six, two-week iterations with releases of the software proof-of-concept at four, six, eight, ten and twelve weeks. Feedback was captured every two weeks during the twelve week "project". Requirements were captured and validated in the team WIKI at every planning meeting (i.e. No Paper, no documents, just a list of well thought-out requirements). The requirements were turned into something called "User Stories" which in Software Engineering equates to lower level requirements that can be written as test cases. As user expectations changed, the requirements changed and the user stories changed. Every two weeks the requirements, user stories and changes were re-shuffled in priority so that the software still worked with each new release (again... every two weeks). At the end of the twelve-week "proof-of-concept" we were done. DONE DONE. There was no longer a need for an RFP, no longer a need for a three-to-six month lag in the bidding process. No vendor manipulation of the bidding process through their relationships with government executives. Just Plain DONE. We went through a separate Independent Validation and Verification (IV&V) because nobody believed we were really done.

If I contrast this "rouge" task order with how traditional life-cycles look inside the government you begin to see the problem: it is not in the interests of most federal contractors to deliver this way and it isn't in the interests of legislators who approve the FAR to allow work to be done this way. Once the job is done done, then you have to find the next job instead of drawing out the lifecycle in what has become the middle-class welfare system. In reality, if you deliver this way, people beat a path to your door and there is no end of work because... people are smart and come up with new ways of doing things.

John has hit the nail on the head: you can talk about what you are going to do and create a requirements document, or you can just get it done and document along the way. My vote is for doing and not wasting OUR money talking.

ooo. This sounded really terse. Sorry. :-)

Permalink Reply by Dennis McDonald on June 24, 2009 at 10:48am

Devin, Agile is not a panacea. Check this blog post out which reviews a very interesting article that convincingly demonstrates situations in which Agile actually stifles innovation:

"How Can Collaboration Systems and Social Media Complement Agile Project Management?"

http://www.ddmcd.com/agile.html

Regarding requirements, I totally agree that we need to be able to respond to changing situations, and I'd be happy if statement of work would at least describe "who what when where when how" in enough quantitative and qualitative detail to enable a contractor other than an incumbent to understand situations that people are increasingly being asked to bid on on a fixed price basis!

Dennis D. McDonald, Ph.D.
Alexandria Virginia
Latest blog post:
“For Government Contracting, Defining “Inherently Governmental” is Inherently Difficult”
http://www.govloop.com/profiles/blogs/for-government-contracting

Permalink Reply by Linda Rodden on May 28, 2009 at 10:40am

I believe a core issue is an inability of the Government to define what success looks like for a program. I teach classes on performance based acquisition and there is little to no understanding of how to tell when your program is successful. Developing a sense of where the program is trying to go and how to measure when you are there is far more important than getting industry to help write the requirements. Who should know best what a successful program looks like? Trouble develops when the Government tries to write specs instead of define and measure outcomes. You then get tied up in all the knots of whose solution is it?

Taking the time up front to define some clear goals is important. If the Government can define clear goals and then solicits industry for fair measures then I believe there is a role there for collaboration. When success is defined, figuring out how we measure when we are there is a different exercise. You can also allow for various ways to get there and also the flexibility that John mentions.

Permalink Reply by Dick Field on May 28, 2009 at 10:48am

After 30 years of acquisition experience in public and private sectors, in diverse technologies, and in hardware and services, here are my conclusions on the impediments to good requirements definition --

1. A general decline in general literacy in society. By this, I don't mean simply the ability to string words together in a sentence with proper syntax, spelling, and punctuation. I mean the higher orders of literacy - the ability to fashion the nuances of language to convey a concept or detail effectively to the intended audience. This command of language is something that has been lost in electronic stimuli, lowered education expectations, and sheer laziness.

2. An excess of collaboration and review - the dark side of group think. Individual responsibility to describe a requirement has been diluted and undermined by an excess of participation and inclusion. Too many cooks have spoiled the broth. Cohesion and coherence has been lost in committee-generated products.

3. Fewer program managers and "SMEs" are around who have gained the expertise by walking the walk. The peer-to-peer relationship between program staffs and industry counterparts that once existed has diminished. As a result, the message in a requirements document isn't as clear or persuasive as it once was.

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page