software development Archives

Tag Archive for: software development

The NASA Ames Research Center in Moffett Field, nestled amongst the global headquarters of Google, LinkedIn, Yahoo and Symantec, is home to Carnegie Mellon Silicon Valley. At this campus, graduate students prepare to become the technical leaders of the Fortune 100 companies that surround them.
Professor Cécile Péraire teaches courses out of the CMU ECE Master Program in Software Engineering. With a PhD in software testing, she has a robust background working with the world’s leading software companies.
In the past, Professor Péraire’s classes used Word documents to write and manage requirements and used basic Kanban boards to track work. But those traditional processes didn’t reflect the complex, critical work students would do after graduation. She sought out a SaaS, cloud-based solution that students could use to write, manage and trace requirements. It needed to be user friendly, so students could find value in it quickly and accomplish their work within the term. After in-depth evaluation of five requirements management tools, Professor Péraire selected Jama Software and became a member of Jama’s Innovator Partner Program. “Overall,” she said, “Jama was the one that performed the best and satisfied all the criteria on my list.”

At the start of the term, Professor Péraire introduced the Jama solution to her class and provided an overview of the tool. Thanks in part to Jama eLearning, she quickly learned the basics of the tool to help her students hit the ground running. Students used Jama to collaborate on their term project, which involved developing an application to assist real-life local first responder teams. Students reported that the tool has helped them work in teams more effectively. One student noted: “Jama is a great collaboration platform.”
Students weren’t the only ones to benefit from the introduction of a modern requirements solution. “I used Jama’s Review Center to evaluate my students’ work and provide more frequent and actionable feedback,” says Professor Péraire. She used item-based reviews to comment on specific elements of the students’ projects and help them improve their work throughout the semester. She concluded: “Overall, as the faculty, a tool like Jama provides me with an improved visibility into the students work, and also improves my ability to effectively collaborate with students outside the classroom, for both mentoring and evaluation purposes. For students, the tool reduces overhead in terms of structuring the information so they can focus on content creation and hence maximize learning.”
Interested in trying Jama in an academic setting? Sign up for a free trial and explore our free eLearning to get up and running quickly.
Learn more about how academic institutions, technology incubators and educational foundations can join Jama’s Innovator Partner Program >>

Typically, Product companies share two business goals: Build the right product for their customers and get them to market quickly. I was honored to share the (virtual) stage with analyst Frank Gillett from Forrester Research to talk about some of the massive opportunities for connected devices to solve real-world problems. I mentioned being inspired by an ad campaign from Cisco Systems about “the Internet of everything.”

No more traffics jams. Now that is the magic of technology:

The thing we talked about is the ability of IoT devices to funnel customer feedback and usage data into your future roadmaps, faster. Key topics included:

Best practices for product requirement gathering, prioritizing and socializing
Eight ways connected products change how customers engage with companies
Turning customer data into good product requirements

Watch this webinar now.

There are a couple main themes I’ve seen emerge when discussing speed to market with our customer base.

Iterative Design:

Where you can, use automation within your design – Processes like generative or parameters based design helps you get a lot of the tedious pieces out of the way quickly so you can focus on your value differentiators.

Gone are the days of waiting for the perfect product definition before building starts. Forrester did some research recently where they found that in new product development, only one-third of ideas resulted in positive improvements. The requirements are too numerous and not focused on the right thing: customer value.

Empowerment:

Make sure you have processes and systems in place that empowers your teams to build the right product(s).

Once you know your must-haves, stop spending cycles ensuring they’re perfectly prioritized. What’s more important on a keyboard, the A key or the E key? If it doesn’t matter which gets done first, so stop worrying about it. Jama provides some simple scoring methods in our tool that allows you to look at relative prioritization like WSJF or sentiment scoring.

Once you have an understanding and alignment around relative value, let your teams pull in what they want to work on instead of dictating or pushing a gated process – We’ve found that if everyone understands what the end goals are, who you’re building for and the problems you’re trying to solve, and you’ve empowered them to provide the solution, you’re going to end up with much better products and better engagement. The younger workforce doesn’t want to spend time reading long documents and making sure they follow strict V-Models, they want to be empowered to make decisions and feel enabled to make a difference.

Finally, empower your teams to work on what is actually valuable. Stop spending cycles and effort talking about the same thing over and over again. If you take a systems approach, if you understand how your whole system works together, you can be much more efficient in reusing common assets across teams, programs and products.

If you’d like to watch a complete recording of this webinar, or share it with your team, feel free.

And calculates the costs and losses caused by inferior RM

“Forty to fifty percent.” That’s the percentage of companies that manage the creation, iteration, testing and launch of new products with MS Office, Google Docs and other all-purpose documentation tools, according to research from Gartner’s “Market Guide for Software Requirements Definition and Management Solutions.”

The result? Gartner clients report: Poor requirements definition and management is a major cause of rework and friction between business and IT.

Gartner notes the growing need for Requirements Management (RM) to be applied to continuous processes within IT, business and product delivery organizational areas. New tools and practices have emerged that emphasize collaboration, integrations and definition. These in turn have generated new demand for dedicated RM tools in both hardware and software development. As Gartner notes:

The delivery of effective software solutions begins with the effective capture of the business objectives, desired business outcomes and software requirements. Too often, requirements appear to be the leading source of delivered defects in software.

In choosing a requirements management tools vendor, Gartner advises companies consider, among other factors:

The ability to work in shared versus collaborative environments
Integration to other ADLM tools (Agile, test management)
Support for your chosen development practice (Waterfall versus Agile)
Who will be involved in actively creating, reviewing, approving and consuming requirements?
Regulatory and reporting needs for compliance

Stop chasing down documents in DOORS and focus on the items within them that matter.

For many years, IBM’s Rational DOORS (v.9) has been a widely adopted Requirements Management (RM) tool for teams working with high-compliance systems engineering programs. Because it’s often sold into the enterprise as part of a larger IBM suite, its widespread use is sometimes a matter of default rather than choice.

If you’re like most of today’s systems-driven engineering organizations, you’re primarily in the business of producing complex, ﬁnished products and components, often involving a mix of hardware, software and ﬁrmware. You’re probably also in a hybrid-Agile development environment and figuring out how to scale that effectively.

In business, times change because needs change. Changes driven by the rise in software-driven products, the imperatives of on-time delivery, and extended supply-chain systems threaten to disrupt traditional, legacy manufacturing and engineering processes. Your teams are pressured to accelerate product delivery and manage growing complexity in distributed organization and supply chains, within products, and across a network of interrelated and interdependent products.

Jama is built to serve and evolve with the ways systems engineering teams build products. How is it different? Jama deconstructs documents into actionable items. You can easily see, grab and reuse items, and be confident that they’re current and include all related comments and status. Forget about wordy “reading assignments.” You can share specific work components with your team for review and approval, without the risk of compromising security or access permissions that document shuffling causes. And when it’s time to pull it all together again to submit or archive a controlled document version, Jama can do that, too.

Skeptical? Make us prove it to you. Sign up for a free 30-day trial and give us a shot. No installation required.

In this age of continuous delivery when increased time pressures compound communication breakdowns, keeping teams aligned has never been more important. Methodologies such as Agile and DevOps address these issues, and they require evangelists — plus tools — to support these practices. Jama Product Manager Derwyn Harris weighs in on this piece in CA’s publication, rewrite, on “purposeful collaboration” and how social media conventions within product development software support these teams.

Smart collaboration is critical in any tech endeavor, because moving parts are plentiful. But what does “collaboration” really mean? It’s a spongy word. Are we talking instant-messaging group chats? Scrums? Standups and retrospectives? Brainstorming software?

As the application development process quickly evolves, so must the support system that surrounds it. That means new tools are required, along with new ways of thinking about working together. We asked DevOps pros for a blueprint to the brave new world of teamwork and idea sharing. (You may never get a group email blast again.)

Big Picture First

Ajay Kaul, managing partner of AgreeYa Solutions, starts with some simple truths. “It is very important to communicate effectively with the IT and delivery teams, explaining to them that the real goal is to accelerate time to market and deliver high-quality products,” he says. “The key is getting started with one project and later creating a team of specialists who can spread the DevOps gospel within the organization, whether you are a startup or a large enterprise.”

The essentials of well-designed DevOps collaboration begin before you undertake an initiative. Start with getting buy-in from upper management and addressing any gaps in your employees’ skills, knowledge and availability. “You need to build a competency within the organization,” Kaul says. “You need to select the right tools for automated testing, build-release integration, configuration, deployment, and network and server performance monitoring, among others.”

This early work requires investing time and money upfront, after you determine which tech tools you will need.

Who’s Driving?

You need a champion for this endeavor—typically, the CIO. The champion must create the collaborative environment needed for DevOps to succeed. It’s natural for CIOs to think of technology as an end in itself, but DevOps must be placed in the broader framework of overall business operations. “Instead of thinking how IT can change the world,” says Kaul, “one should think of how business situations inform the changes in IT systems.”

That sets up the CIO in a role as a planner and a manager, not just the technician in chief. CIOs must shift their thinking from focusing only on individual department needs to integrating cross-functional and interdepartmental collaborative teams, Kaul advises. While the CIO plots direction, team members promote the adoption of DevOps on a project-by-project basis. One person is driving the bus, but the passengers are active participants in arriving at the right spot. One key is creating DevOps champions throughout the organization to distribute the workload of DevOps evangelism and DevOps implementation. This approach creates a more natural, collaborative environment, because multiple leaders will be pursuing the strategy in different projects, teams and departments.

The Power of the Social Circle

The basic mechanics of collaboration are familiar to any business professional, particularly in the IT world, where feedback loops are essential for success. On a day-to-day basis, these mechanisms may be as simple as team members relying on messaging platforms to work together and solve problems quickly. Large-scale beta tests are useful when gauging how well a software implementation works. But as projects become faster and more complex and involve additional team members—as in a DevOps environment—such tools are insufficient for managing these workloads. That’s where “purposeful collaboration” comes into play. Purposeful collaboration uses the power of social systems to enhance more traditional tools like instant messaging, email, service desks and cloud-based content sharing.

“Purposeful collaboration uses familiar constructs like those in social media to connect all stakeholders related to the project, both inside and outside the organization, in a meaningful way,” says Derwyn Harris, co-founder of Jama Software, which markets its own collaboration framework. The key word here is “meaningful.” Many so-called collaborative efforts begin with the best of intentions but then devolve by throwing every piece of information at everyone involved. If you’ve ever been frustrated after receiving your 30th message in an endless mass email chain that you should never have been copied on in the first place, you know how aggravating this approach is.

Purposeful collaboration offers information in a more targeted way. For example, all team members may be allowed to comment on a design mockup, while only managers have access to functional requirement documents. Users can then drill down into these comments and relationships to see how various team members have interacted with a certain item within a project. This visibility can help to clarify questions about who may be impacted if that item is changed or delayed.

The Death, Finally, of the Blast Email

How this process works depends on the specific tool used. For instance, a rich graphical interface can visually display how one individual’s work connects with the work of every other team member. This insight allows team members to drill down into any component of a product or aspect of a decision, so they can make better decisions in less time. It also includes indicators showing the scope of conversations and associated decisions, so users can immediately reach out to the right person.

“Purposeful collaboration connects the right people to the right work,” Harris says. “It is the antithesis of a blast email sent to hundreds of people.”

Ultimately, the goal is to make the collaborative environment a savvy alternative to slower, cruder communications methods. “It makes everyone’s job infinitely easier,” says Harris.

I’m thrilled to introduce a new version of Jama. Over the weekend, we upgraded Jama to our SaaS customers. This release marks our continued focus on providing organizations and teams a central place to manage and communicate their product definition, development and deployment. At the core of the new features for this release, we’ve linked two concepts together: collaboration and traceability. Over the years, these have been considered separate and disconnected. Traceability ensured coverage and referred to the relationship between test cases and requirements. We see traceability as much more, as the connecting (“steel”) thread between the core business value of the product and the work, down to the item level, performed by every member of the extended product team.

By merging the concepts of traceability with collaboration, we’ve introduced in Jama a set of visualization features that clearly show who across the organization is connected to the work. When someone needs a decision or a question to move forward, they can instantly reach out to the right people for real-time action. Product development is all about negotiations and trade-offs. You start with this beautiful idea of what you want to build, and then the reality of what ultimately comes out at the end requires decisions and compromises. If everyone on your team has a clear understanding of the steel thread, they’ll make the right decisions, navigate through the technical complexities and contribute elegantly to the business outcomes.

For example, the Jama product team captures around 72 product-related decisions per day. This is a one-product, agile team working in one location. The biggest majority of organizations we work with are much larger – consider how many decisions are escaping view from the organization. Conversations that would otherwise be lost in meetings, in email or buried in documents somewhere are captured in the Jama Stream, connected to the work. Now, with the new Connected Users features, users can trace not only the decisions and conversations back to the work, but also the people directly, and indirectly, vested in the outcome of each decision. This insight can dramatically speed the development process and result in better product outcomes.

The Spring release also introduces Relationship Rules, a visual diagram to define and standardize data so users can see how their data fits into the entire product delivery process. This feature prevents users from connecting incorrect data and ensures full traceability.

To learn more about these new features check out the video below, see the press release and read the release notes.

In the first part of this two-part series I described the value of managing risks formally on a software project and listed numerous common risks in various categories. This article describes the various activities associated with the practice of risk management and recommends specific information you should record about each risk you identify.

Risk Management Components

As with other project activities, begin risk management by developing a plan, perhaps using the risk management plan template available at www.ProjectInitiation.com. Small projects can include a concise risk management plan as a section within the overall project plan. Risk management consists of the activities illustrated in Figure 1 and described below.

Risk Assessment

Risk assessment is the process of examining a project to identify areas of potential risk. Risk identification can be facilitated with the help of a checklist of common risk areas for software projects, as I described in the first article in this series. Risk analysis examines how project outcomes might change with modification of risk input variables. In other words, just how could the risk harm your project.

Figure 2: Risk exposure is a function of probability and potential loss.

Risk prioritization helps the project focus on its most severe risks by assessing the risk exposure. Exposure is the product of the probability of incurring a loss due to the risk and the potential magnitude of that loss. I usually estimate the probability from 0.1 (highly unlikely) to 1.0 (certain to happen), and the loss (also called impact) on a relative scale of 1 (no problem) to 10 (deep tapioca). Multiplying these factors together provides an estimate of the risk exposure due to each item, which can run from 0.1 (don’t give it another thought) through 10 (stand back, here it comes!). It’s simpler to estimate both probability and loss as High, Medium, or Low. Figure 2 shows how you can estimate the risk exposure level as High, Medium, or Low by combining the probability and loss estimates.

Risk Avoidance

Risk avoidance is one way to deal with a risk: don’t do the risky thing! You might avoid risks by not undertaking certain projects, or by relying on proven rather than cutting-edge technologies when possible. You might be able to transfer a risk to some other party, such as a subcontractor.

Risk Control

Risk control is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, owners, and timelines. Risk resolution entails executing the plans for dealing with each risk. That’s when you actually control the risk. Finally, risk monitoring involves tracking your progress toward resolving each risk item.

Let’s look at an example of risk management planning. Suppose the “project” is to take a hike through a swamp in a nature preserve. You’ve heard the swamp might contain quicksand, so the risk is that we might step in quicksand and be injured or even die. One strategy to mitigate this risk is to reduce the probability of the risk actually becoming a problem. A second option is to consider actions that could reduce the impact of the risk if it does in fact become a problem. So, to reduce the probability of stepping in the quicksand, we might look for signs of quicksand as we walk and draw a map so we can avoid these areas on future walks. To reduce the impact if someone does step in quicksand, the members of the tour group could rope themselves together. That way if someone does encounter some quicksand the others could quickly pull him to safety.

Even better, is there some way to prevent the risk from becoming a problem under any circumstances? Maybe we build a boardwalk as we go so we avoid the quicksand. That will slow us down and cost some money. But, we don’t have to worry about quicksand any more. The very best strategy is to eliminate the root cause of the risk entirely. Perhaps we should drain the swamp, but then it wouldn’t be a very interesting nature walk. By taking too aggressive a risk approach, you can eliminate the factors that make a project attractive in the first place.

Documenting Risks

Simply identifying the risks facing a project is not enough. We need to write them down in a way that lets us communicate the nature and status of risks throughout the affected stakeholder community over the duration of the project. Figure 3 shows a form I’ve found to be convenient for documenting risks. It’s a good idea to keep the risk list itself separate from the risk management plan, as you’ll be updating the risk list frequently throughout the project. You can download an alternative template for your risk list from www.ProjectInitiation.com. This format includes essentially the same information that’s in Figure 3, but it’s laid out in a way that’s amenable to storing in a spreadsheet or as a table in a word-processing document.

ID: <sequence number or a more meaningful label>
Description: <List each major risk facing the project. Describe each risk in the form “condition – consequence.”>
Probability: <What’s the likelihood of this risk becoming a problem?>	Loss: <What’s the damage if the risk does become a problem?>		Exposure: <Multiply Probability times Loss.>
First Indicator: <Describe the earliest indicator or trigger condition that might indicate that the risk is turning into a problem.>
Mitigation Approaches: <State one or more approaches to control, avoid, minimize, or otherwise mitigate the risk.>
Owner: <Assign each risk mitigation action to an individual for resolution.>		Date Due: <State a date by which the mitigation approach is to be implemented.>

Figure 3: A risk documentation form.

Use a condition–consequence format when documenting risk statements. That is, state the risk situation (the condition) that you are concerned about, followed by at least one potential adverse outcome (the consequence) if that risk should turn into a problem. Often, people suggesting risks state only the condition—“The customers don’t agree on the product requirements”—or the consequence—“We can only satisfy one of our major customers.” Pull those together into the condition-consequence structure: “The customers don’t agree on the product requirements, so we’ll only be able to satisfy one of our major customers.” This statement doesn’t describe a certain future, just a possible outcome that could harm the project if the condition isn’t addressed.

Keep the items with high risk exposures at the top of your priority list to focus your risk-control energy. Set goals for determining when each risk item has been satisfactorily controlled. Your mitigation approaches for some items may focus on reducing the probability, whereas the approach for other risks could emphasize reducing the potential loss or impact. With any luck, some of your mitigation strategies will help you control multiple risk factors.

Risk Tracking

As with other project management activities, you need to get into a rhythm of periodic monitoring. You may wish to appoint a risk manager for the project. The risk manager is responsible for staying on top of the things that could go wrong, just as the project manager stays on top of the activities leading to project completion. It’s a good idea to have someone other than the project manager serve as the risk manager. The project manager is focused on what he has to do to make a project succeed. The risk manager, in contrast, is identifying factors that might prevent the project from succeeding. In other words, the risk manager is looking for the black cloud around the silver lining that the project manager sees. Asking the same person to take these two opposing views of the project can lead to cognitive dissonance; in an extreme case, his brain can explode.

Keep the top ten risks highly visible and track the effectiveness of your mitigation approaches regularly. New risks might float up into the top ten as you gradually beat the initial list of top priority items into submission. You can drop a risk off your radar when your mitigation approaches have reduced the risk exposure from that item to an acceptable level. Don’t conclude that a risk is controlled simply because the selected mitigation action has been completed. Controlling a risk might require you to change the risk control strategy if you conclude it isn’t working.

A student in a seminar once asked, “What should you do if you have the same top five risks week after week?” A static risk list suggests that your risk mitigation actions aren’t working. Effective mitigation actions should lower the risk exposure as the probability, the loss, or both decrease over time. If your risk list isn’t changing, check to see whether the planned mitigation actions have been carried out and whether they had the desired effect.

Also, look for new risks that might arise during the course of the project. Conditions can change, assumptions can prove to be wrong, and other factors might lead to risks that weren’t apparent or perhaps did not even exist at the beginning of the project. Escalate risks that aren’t being controlled to the attention of senior managers or other stakeholders. They can then either stimulate corrective actions or else make a conscious business decision to proceed in spite of the risks.

Learning from the Past

We can’t predict exactly which of the many threats to our projects might come to pass. However, most of us can do a better job of learning from previous experiences to avoid the same pain and suffering on future projects. As you begin to implement risk management approaches, record your actions and results for future reference. The risks are out there. Find them before they find you.

Also read Knowing Your Enemy: An Introduction to Risk Management, Part 1

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.

As the new training manager at Jama I’ve been working with our team in 2014 to bring you new educational options, and I’m happy to announce that our first set is now available for free to existing customers.

It’s my pleasure to introduce the tutorial set: Get Started with Jama. These short videos will have you up and running in Jama in less than an hour. All of the videos are under five minutes long, and many run half that. You can access the videos via the welcome screen in Jama.

If you’ve been a customer for a while, you may have turned the welcome screen off, so here’s how you turn it on again. First, click on your name in top right-hand corner.

Then select this box to access the welcome screen again.

Log out and back in, and you’ll have the screen. Click Learn Jama Basics, and you’re there.

Do you have new employees? Show them this post and get them started quickly in the tool. Need a refresher on functionality you haven’t used in a while? Watch what you need. Please, feel free to share this with anyone who’s using Jama. We want you to be able to pick up and use our tool as easily as possible.

We’d love to hear what you think of these videos! Feel free to leave a comment below, or if you’d prefer to reach out to us directly, email us at education@jamasoftware.com. Keep an eye out for more Jama training announcements soon.

Software engineers are eternal optimists. When planning software projects, we usually assume that everything will go exactly as planned. Or, we take the other extreme position: the creative nature of software development means we can never predict what’s going to happen, so what’s the point of making detailed plans? Both of these perspectives can lead to software surprises, when unexpected things happen that throw the project off track. In my experience, software surprises are never good news.

Risk management has become recognized as a best practice in the software industry for reducing the surprise factor. Although we can never predict the future with certainty, we can apply risk management practices to peek over the horizon at the traps that might be looming. Then we can take actions to minimize the likelihood or impact of these potential problems. Risk management means dealing with a concern before it becomes a crisis. This improves the chance of successful project completion and reduces the consequences of those risks that cannot be avoided.

During project initiation take the time to do a first cut at identifying significant risks. It’s possible that the risks will outweigh the potential benefits of the project. More likely, getting an early glimpse of potential pitfalls will help you make more sensible projections of what it will take to execute this project successfully. Build time for risk identification and risk management planning into the early stages of your project. You’ll find that the time you spend assessing and controlling risks will be repaid many times over.

What Is Risk?

A “risk” is a problem that could cause some loss or threaten the success of your project, but which hasn’t happened yet. And you’d like to keep it that way. These potential problems might have an adverse impact on the cost, schedule, or technical success of the project, the quality of your products, or team morale. Risk management is the process of identifying, addressing, and controlling these potential problems before they can do any harm.

Whether we tackle them head-on or keep our heads in the sand, risks have a potentially huge impact on many aspects of our project. The tacit assumption that nothing unexpected will derail the project is simply not realistic. Estimates should incorporate our best judgment about the potentially scary things that could happen on each project, and managers need to respect the assessments we make. Risk management is about discarding the rose-colored glasses and confronting the very real potential of undesirable events conspiring to throw the project off track.

Why Manage Risks Formally?

A formal risk management process provides multiple benefits to both the project team and the development organization as a whole. First, it gives us a structured mechanism to provide visibility into threats to project success. By considering the potential impact of each risk item, we can focus on controlling the most severe risks first. We can marry risk assessment with project estimation to quantify possible schedule slippage if certain risks materialize into problems. This approach helps the project manager generate sensible contingency buffers. Sharing what does and does not work to control risks across multiple projects helps the team avoid repeating the mistakes of the past. Without a formal approach, we cannot ensure that our risk management actions will be initiated in a timely fashion, completed as planned, and effective.

Controlling risks has a cost. We must balance this cost against the potential loss we could incur if we don’t address the risk and it does indeed bite us. Suppose we’re concerned about the ability of a subcontractor to deliver an essential component on time. We could engage multiple subcontractors to increase the chance that at least one will come through on schedule. That’s an expensive remedy for a problem that might not even materialize. Is it worth it? It depends on the downside we incur if indeed the subcontractor dependency causes the project to miss its planned ship date. Only you can decide for each individual situation.

Typical Software Risks

The list of evil things that can befall a software project is depressingly long. The enlightened project manager will acquire lists of these risk categories to help the team uncover as many concerns as possible early in the planning process. Potential risks to consider can come from group brainstorming activities or from a risk factor chart accumulated from previous projects. In one of my groups, individual team members came up with descriptions of the risks they perceived, which I edited together and we then reviewed as a team.

Following are several typical risk categories and some specific risks that might threaten your project. Have any of these things have happened to you? If so, add them to your master risk checklist to remind future project managers to consider if it could happen to them, too. There are no magic solutions to any of these risk factors. We need to rely on past experience and a strong knowledge of software engineering and management practices to control those risks that concern us the most.

Dependencies

Some risks arise because of dependencies our project has on outside agencies or factors. We cannot usually control these external dependencies. Mitigation strategies could involve contingency plans to acquire a necessary component from a second source, or working with the source of the dependency to maintain good visibility into status and detect any looming problems. Following are some typical dependency-related risk factors:

Customer-furnished items or information.
Internal and external subcontractor relationships.
Inter-component or inter-group dependencies.
Availability of trained and experienced people.
Reuse from one project to the next.

Requirements Issues

Many projects face uncertainty and turmoil around the product’s requirements. Some uncertainty is tolerable in the early stages, but the threat increases if such issues remain unresolved as the project progresses. If we don’t control requirements-related risks we might build the wrong product or build the right product badly. Either outcome results in unpleasant surprises and unhappy customers. Watch out for these risk factors:

Lack of a clear product vision.
Lack of agreement on product requirements.
Inadequate customer involvement in the requirements process.
Unprioritized requirements.
New market with uncertain needs.
Rapidly changing requirements.
Ineffective requirements change management process.
Inadequate impact analysis of requirements changes.

Management Issues

Although management shortcomings affect many projects, don’t be surprised if your risk management plan doesn’t list too many of these. The project manager often leads the risk identification effort, and most people don’t wish to air their own weaknesses (assuming they even recognize them) in public. Nonetheless, issues like those listed here can make it harder for projects to succeed. If you don’t confront such touchy issues, don’t be surprised if they bite you at some point. Defined project tracking processes and clear project roles and responsibilities can address some of these conditions.

Inadequate planning and task identification.
Inadequate visibility into project status.
Unclear project ownership and decision making.
Unrealistic commitments made, sometimes for the wrong reasons.
Managers or customers with unrealistic expectations.
Staff personality conflicts.

Lack of Knowledge

Software technologies change rapidly and it can be difficult to find suitably skilled staff. As a result, our project teams might lack the skills we need. The key is to recognize the risk areas early enough so we can take appropriate preventive actions, such as obtaining training, hiring consultants, and bringing the right people together on the project team. Consider whether the following factors apply to your team:

Lack of training.
Inadequate understanding of methods, tools, and techniques.
Insufficient application domain experience.
New technologies or development methods.
Ineffective, poorly documented, or ignored processes.
Technical approaches that might not work.

Outsourcing

Outsourcing development work to another organization, possibly in another country, poses a whole new set of risks. Some of these are attributable to the acquiring organization, others to the supplier, and still others are mutual risks. If you are outsourcing part of your project work, watch out for the following risks:

Acquirer’s requirements are vague, ambiguous, incorrect, or incomplete.
Acquirer does not provide complete and rapid answers to supplier’s questions or requests for information.
Supplier lacks appropriate software development and management processes.
Supplier does not deliver components of acceptable quality on contracted schedule.
Supplier is acquired by another company, has financial difficulties, or goes out of business.
Supplier makes unachievable promises in order to get the contract.
Supplier does not provide accurate and timely visibility into actual project status.
Disputes arise about scope boundaries based on the contract.
Import/export laws or restrictions pose a problem.

The second article in this series will describe the various activities associated with the practice of risk management and recommend the specific bits of information you should record about each risk you identify.

Also read Know Your Enemy: An Introduction to Risk Management, Part 2

As every consultant knows, the correct answer to nearly any question regarding software is “It depends.” I realize that’s not a very satisfying answer, but this isn’t just a consultant’s cop-out—it’s true. The best advice for how to proceed in a given situation depends on the nature of the project, its constraints, the culture of the organization and team, the business environment, and other factors.

That said, having worked with many organizations, I’ve made some observations about software requirements that really do seem to be universally applicable. In this series of three articles (adapted from my book More about Software Requirements) I present some of these “cosmic truths” and their implications for the practicing business analyst.

Cosmic Truth #1: If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.

Requirements serve as the foundation for all the project work that follows. I don’t mean the initial software requirements specification you come up with early in the project, but rather the full set of requirements knowledge that is developed incrementally during the course of the project.

The purpose of a software development project is to build a product that provides value to a particular set of customers. Requirements development attempts to determine the mix of product capabilities and characteristics that will best deliver this customer value. This understanding evolves over time as customers provide feedback on the early work and refine their expectations and needs. If this set of expectations isn’t adequately explored and crafted into a set of product features and attributes, the chance of satisfying customer needs is slim.

Requirements validation is one of the vital subcomponents of requirements development, along with elicitation, analysis, and specification. Validation involves demonstrating that the specified requirements will meet customer needs. One useful technique for validating requirements is to work with suitable customer representatives to develop user acceptance criteria. These criteria define how customers determine whether they’re willing to pay for the product or to begin using it to do their work. User acceptance criteria typically stipulate that the product allows the users to properly perform their most significant tasks, handles the common error conditions, and offers an acceptable level of quality. User acceptance criteria aren’t a substitute for thorough system testing. They do, however, provide a necessary perspective to determine whether the requirements are indeed right.

Cosmic Truth #2: Requirements development is a discovery and invention process, not just a collection process.

People often talk about “gathering requirements.” This phrase suggests that the requirements are just lying around waiting to be picked like flowers or to be sucked out of the users’ brains by the BA. I prefer the term requirements elicitation to requirements gathering. Elicitation includes some discovery and some invention, as well as recording those bits of requirements information that customer representatives offer to the BA. Elicitation demands iteration. The participants in an elicitation discussion won’t think of everything they’ll need up front, and their thinking will change as the project continues. Requirements development is an exploratory activity.

A business analyst is not simply a scribe who records what customers say. The BA is an investigator who asks questions that stimulate the customers’ thinking, seeking to uncover hidden information and generate new ideas. It’s fine for a BA to propose requirements that might meet customer needs, provided the customers agree that those requirements add value before they go into the product. A BA might ask customers, “Would it be helpful if the system could do?” The customer might reply, “No, that wouldn’t do much for us.” Alternatively, the customer might reply, “You could do that? Wow, that would be great! We didn’t even think to ask for that feature, but it would save our users a lot of time.”

This creativity is part of the value the BA adds to the requirements conversation. Just be careful that BAs and developers don’t attempt to define a product from the bottom up through suggested product features. It’s better to base the requirements on an understanding of stakeholder goals and a broad definition of success.

Cosmic Truth #3: Change happens.

It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are updated, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are.

The objective of a change control process is not to inhibit change. Rather, the objective is to manage change to ensure that the project incorporates the right changes for the right reasons. You need to anticipate and accommodate changes to produce the minimum disruption and cost to the project and its stakeholders. However, excessive churning of the requirements after they’ve been agreed upon suggests that elicitation was incomplete or ineffective—or that agreement was premature.

To help make change happen, establish a change control process. You can download an example of such a process from the Process Impact website. When I helped to implement a change control process in an Internet development group at Kodak, the team members properly viewed it as a useful structure, not as a barrier. The group found this process invaluable for dealing with its mammoth backlog of change requests.

Every project team also needs to determine who will evaluate requested changes and decide to approve or reject them. This group is typically called the change (or configuration) control board, or CCB. A CCB should write a charter that defines its composition, scope of authority, operating procedures and decision-making process. A template for such a charter also is available at the Process Impact website.

Nearly every software project becomes larger than originally anticipated, so expect your requirements to grow over time. According to consultant Capers Jones, requirements growth typically averages one to three percent per month during design and coding. This can have a significant impact on a long-term project. To accommodate some expected growth, build contingency buffers—also known as management reserve—into your project schedules. These buffers will keep your commitments from being thrown into disarray with the first change that comes along.

I once spoke with a manager on a five-year project regarding requirements growth. I pointed out that, at an average growth rate of two percent per month, his project was likely to be more than double the originally estimated size by the end of the planned sixty-month schedule. The manager agreed that this was plausible. When I asked if his plans anticipated this growth potential, he gave the answer I expected: No. I was highly skeptical that this project will be completed without enormous cost and schedule overruns.

When you know that requirements are uncertain and likely to change, use an incremental or iterative development life cycle. Don’t attempt to get all the requirements “right” up front and freeze them. Instead, specify and baseline the first set of requirements based on what is known at the time. A baseline is a statement about the state of the requirements at a specific point in time: “We believe that these requirements will meet a defined set of customer needs and are a suitable foundation for proceeding with design and construction.” Then, implement that fraction of the product, get some customer feedback, and move on the next slice of functionality. This is the intent behind agile development methodologies, the spiral model, iterative prototyping, evolutionary delivery, and other incremental approaches to software development.

Finally, recognize that change always has a price. It is never free. Even the act of considering a proposed change and then rejecting it consumes effort. Software people need to educate their project stakeholders so they understand that, sure, we can make that change you just requested, and here’s what it’s going to cost. Then the stakeholders can make appropriate business decisions about which desired changes should be incorporated and at what time.

Speaking of which, the next article in this series will present several cosmic truths about requirements and project stakeholders.

Read the Cosmic Truths about Software Requirements, Part 2.

Read the Cosmic Truths about Software Requirements, Part 3.