Requirement Elicitation and Documentation Requires Collaboration, not Word Processing

A recent analysis of enterprise software initiatives and of commercially available requirements management tools determined that 91% of participants used word processing programs to define and document system requirements. Many people believe that a simple list is sufficient to identify and communicate requirements to the development/implementation team. Still, from a practical perspective, it’s important to point out that Word Process applications were not designed for documenting and tracing requirements.

Also, large word processing documents are not easily reviewed, shared, or amended across the cross-functional teams of business and technology users involved in a project roll-out. This approach also results in extreme version control issues and ideas and suggesting being overlooked.  Reviewing large text-based documents often results in missing requirements or defects not detected. In addition, using documents, feedback from stakeholders rarely occurs until the individuals are affected, which can be as late as during testing or development.

To be effective, requirements development should be incremental, iterative, and collaborative.  Stakeholders should be able to review requirements as they are developed and make comments when they feel that the requirements do not address their needs. Comments should be documented and tracked.  Organizations should use a collaborative tool to define requirements and not a word processing application that was never designed to develop or manage requirements.

With projects needing collaboration and interaction to succeed -- and requirements needing to be created, collected, and easily applied -- the notion of using large text-based documents is simply flawed. Nevertheless, it doesn’t stop companies for compiling single gigantic text documents, and then being frustrated with poor results and dissatisfied users.

Rather, the focus for effective requirements management needs to shift from document-centric to data-centric. Requirements should be managed in bundles that can be accessed, reviewed, and enhanced online. These bundled requirements should be more than just text. They should reference a wealth of data, including graphics, stakeholder comments and clarifications, and information on regulations, competitive offerings, company policies, and business rules. To access this data, stakeholders and developers should be able to use flexible search capabilities and hierarchical links of structured information.

Failure to use the right tool for defining requirements will result in an unhappy business community because of issues such as:

• Missing or Incomplete Requirements – It is always best to elicit, analyze, and specify requirements in a structured fashion. It is very difficult to accomplish this using a general-purpose tool such as Word or Excel. Failure to gather requirements in a structured fashion often leads to incomplete requirements, which is one of the major reasons for project failure according to a study by The Standish Group.
• Misunderstood Requirements – Good requirements are generally documented with more that text.  Supplemental requirement documentation may include graphic illustrations, discussions, business process models, videos, and links or references to other documents. It is difficult if not impossible to capture this type of information in Word or Excel.  Requirements are often misunderstood when they are not elaborated with additional types of information.
• Lack of Support for Requirements – Buy-in and active stakeholder support is essential for developing good requirements as the foundation for software development and testing.  People are reluctant to buy into a gigantic text based document which they did not author.  These large text documents are intimidating and overwhelming for most people; people provide a cursory review and reluctantly accept them, but do not buy in to them. A collaborative tool works significantly better than a large text based document to get stakeholder participation and buy-in.
• Incorrect Requirements- Requirements documents that are created using a general purpose tool such as Excel or Word usually are usually stored on the author's computer, and are not accessible by others in real-time. This makes it difficult to share, discuss, validate, and track changes, which frequently leads to incorrect requirements.  When word documents are distributed, the author loses control and almost always has a version control problem. Redistributing different versions of the same word document is error prone, awkward, and simply not practical for large teams. Requirement teams should be able to view, edit, and comment on requirements in real time.
• Lost Requirements - It is easy for requirements to drop through the cracks when using general purpose tools such as Word or Excel.  Critical requirements can be lost when the author forgets, is reassigned, or leaves the organization.  The collaborative tools need to provide a comprehensive trackability.
• Inability to Support Iterative Development – Many organizations are using agile or other forms of iterative development. Many of these methods require prioritization of requirements and organization of the requirements into a bundle that fits a development iteration. It is simply impractical to try to accomplish this with Word. The iterations are very short and the team must know what the requirements are before the iteration begins. This requires a data driven approach to requirements versus a document driven approach as the requirements are maintained in backlog, sized and prioritized. Using the sizing and priorities, requirements are identified and planned for development iterations.

Business, User, and System Requirements

A solution may contain only software components, or it could incorporate both software and hardware components. It may also include training and organizational change requirements that will be provided to instructional designers to develop a comprehensive training program. Software requirements represent the system’s functional and supplemental requirements that define the software components of the system.

Traditionally, functional and supplemental requirements for software were documented in the software requirements specification (SRS). The SRS is the principal deliverable that analysts use to communicate detailed requirements information to developers, testers, and other project stakeholders. Many modern systems, such as the Enfocus Requirement Suite,™ place requirements into multiple requirement bundles to support iterative development and to break requirements into various components required by teams to develop the solution (e.g., software, hardware, organizational change, etc.) Requirement bundles provide more flexibility than URD and SRS.  Requirement bundles may be developed iteratively and incrementally with both stakeholders and project team members being able to validate and review the requirements as they evolve. User needs are always mapped to system requirements so that the developer sees not only the requirement but the source from where it originated.

Requirements Engineering Process Assets

High-performance projects have effective processes for all of the requirements engineering components: elicitation, analysis, specification, validation, and management. To facilitate the performance of these processes, every organization needs a collection of appropriate process assets. A process encompasses the actions you take and the deliverables you produce; process assets help the team members perform those processes consistently and effectively. These process assets will help those involved in the project understand the steps they should follow and the work products they’re expected to create.

Table 1 identifies some valuable process assets for requirements engineering. No software process rule book says that you need all of these items, but they will all assist your requirements-related activities. Procedures should be no longer than they need to be to let team members consistently perform the tasks effectively. They need not be separate documents. For instance, an overall requirements management process could include the change control procedure, status tracking procedure, and impact analysis checklist.

Following are brief descriptions of each of these process assets. Many of these are available at http://www.processimpact.com/goodies.shtml. Keep in mind that each project should tailor the organization’s assets to best suit its needs.

Table 1. Key process assets for requirements development and requirements management.

Requirements Development Process Assets

Requirements development process. This process describes how to identify stakeholders, user classes, and product champions in your domain. It should address how to plan the elicitation activities, including selecting appropriate elicitation techniques, identifying participants, and estimating the effort and calendar time required for elicitation. The process describes the various requirements documents and models your project is expected to create and points the reader toward appropriate templates. The requirements development process also should identify the steps the project should perform for requirements analysis and validation.

Requirements allocation procedure. Allocating high-level product requirements to specific subsystems (including people) is necessary when developing systems that include both hardware and software components or complex products that contain multiple software subsystems. Allocation takes place after the system-level requirements are specified and the system architecture has been defined. This procedure describes how to perform these allocations to ensure that functionality is assigned to the appropriate components. It also describes how you will trace allocated requirements back to their parent system requirements and to related requirements in other subsystems.

Requirements prioritization procedure.  To sensibly reduce scope or to accommodate added requirements within a fixed schedule, we need to know which planned system capabilities have the lowest priority. I’ve developed a spreadsheet tool for prioritization (at http://www.processimpact.com/goodies.shtml) that incorporates the value provided to the customer, the relative technical risk, and the relative cost of implementation for each feature, use case, or functional requirement.

Vision and scope template. Step 1 for managing the dreaded specter of scope creep is to document the project’s scope someplace, so we can judge whether proposed new requirements are in or out of scope. The vision and scope document is a concise, high-level description of the new product’s business requirements. It delineates what’s in and what’s out, thereby providing a reference for making decisions about requirements priorities and changes.

Use-case template. The use-case template provides a standard way to describe tasks that users need to perform with a software system. A use-case definition includes a brief description of the task, descriptions of alternative behaviors and known exceptions that must be handled, and additional information about the task.

Software requirements specification template. The SRS template provides a structured, consistent way to organize the functional and nonfunctional requirements for whatever product you’re building. Consider adopting more than one template to accommodate the different types or sizes of projects your organization undertakes. This can reduce the frustration that arises when a “one size fits all” template or procedure isn’t suitable for your project.

SRS and use-case defect checklists. Formal inspection of requirements documents is a powerful software quality technique. An inspection defect checklist identifies many of the errors commonly found in requirements documents. Use the checklist during the inspection’s preparation stage to focus your attention on common problem areas.

Requirements Management Process Assets

Requirements management process. This process describes the actions a project team takes to deal with changes, distinguish versions of the requirements documentation, track and report on requirements status, and accumulate traceability information. The process should list the attributes to include for each requirement, such as priority, predicted stability, and planned release number. It should also describe the steps required to approve the SRS and establish the requirements baseline.

Change control process. A practical change control process can reduce the chaos inflicted by endless, uncontrolled requirements changes. The change control change process defines the way that a new requirement or a modification to an existing requirement is proposed, communicated, evaluated, and resolved. A problem-tracking tool facilitates change control, but remember that a tool is not a substitute for a process.

Requirements status tracking procedure. Requirements management includes monitoring and reporting the status of each functional requirement. You’ll need to use a database or a commercial requirements management tool to track the status of the many requirements in a large system. This procedure should also describe the reports you can generate to view the status of the collected requirements at any time.

Change control board charter. The change control board (CCB) is the body of stakeholders that decides which proposed requirements changes to approve, which to reject, and in which product release or iteration each approved change will be incorporated. The CCB charter describes the composition, function, and operating procedures of the CCB. It’s worth taking the time to describe how a group of key decisionmakers will collaborate.

Requirements change impact analysis checklist and template. Estimating the cost and other impacts of a proposed requirement change is a key step in determining whether to approve the change. Impact analysis helps the CCB make smart decisions. An impact analysis checklist helps you contemplate the possible tasks, side effects, and risks associated with implementing a specific requirement change. An accompanying worksheet provides a simple way to estimate the labor for the tasks.

Requirements traceability matrix template. The requirements traceability matrix lists all the functional requirements, the design components and code modules that address each requirement, and the test cases that verify its correct implementation. The traceability matrix should also identify the parent system requirement, use case, business rule, or other source from which each functional requirement was derived.

Simply passing out a bunch of process documents to your team members is no guarantee of success. Well-meaning improvement leaders sometimes get carried away, creating much more process documentation than they need.  Your process materials should be light enough to be unintimidating, practical, and effective—but no lighter.

Enterprise Architecture Requirements

Globalization, increasing regulation, and faster cycle times demand that an organization has the ability to quickly change its business processes. Business agility is becoming a strategic necessity. One of the key methods to achieve business agility is to have a well defined enterprise architecture.  According to research conducted by Jeanne Ross, Peter Weill, and David Robertson in their book, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution (2006),

“Companies with a foundation for execution supporting an operating model (e.g., well defined enterprise architecture) reported 17 percent greater strategic effectiveness than other companies—a metric positively correlated with profitability. These companies also reported higher operational efficiency (31%), customer intimacy (33%), product leadership (34%), and strategic agility (29%) than companies that had not developed a foundation for execution.”

However, for many companies, the term architecture has a negative connotation. Many companies have questioned the value of their architecture initiatives and viewed them as IT theory isolated from business reality. This is unfortunate, but there are several reasons why defining architecture has been nothing more than a worthless training exercise for many companies. The two main reasons are that the enterprise architectures are not connected at the top with an operating manual and not connected at the bottom with a solid requirement management process. Let’s address both of these issues.

An operating model describes how a company will grow and prosper. The choice of an operating model is a critical corporate decision.  The operating model enables rapid implementation of a range of strategic initiatives, but that same operating model will fail when initiatives are undertaken that are not based on the assumptions of the operating model.  Selecting an operating model is a tough decision and is a commitment of doing business a certain way.  The operating model decision should drive how an organization implements business processes and IT infrastructure.

Enterprise architectures that are developed without choosing an appropriate operating model will not work. An operating model has two dimensions: business process standardization and business process integration, which are represented as the x and y axis of a matrix.  Process standardization delivers efficiency and predictability across the company.  Integration links the efforts of organizational units through shared data.  The table below illustrates the four types of operating models. After reviewing this matrix for only a few minutes, it is easy to see why organizations which embark on implementing an enterprise architecture without first defining and obtaining a clear understanding of their operating model often end up with worthless piles of paper.

  

There are many frameworks for defining Enterprise Architectures including:

• The Zachman Framework for Enterprise Architectures
• The Open Group Architecture Framework (TOGFA)
• Federal Enterprise Architecture (FEA)
• NIST Enterprise Architecture Model
• Gartner Group

The two most used are probably the Zachman Framework and TOGFA. The Zachman "Framework" is actually a taxonomy for organizing architectural artifacts (design documents, specifications, and models). It takes into account both who the artifact targets (for example, business owner and developer) and what particular issue is being addressed. John Zachman, the creator, retrospectively described his work:

“The [Enterprise Architecture] Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise, as well as to the development of the Enterprise's systems.”

TOGAF describes itself as a "framework," but the most important part of TOGAF is the Architecture Development Method, better known as ADM. ADM is a methodology for creating an enterprise architecture. TOGAF complements the Zachman framework; Zachman tells you how to categorize your artifacts; TOGAF gives you a process for creating them. TOGAF addresses four levels of architecture:

• Business process architecture
• Data architecture
• Applications architecture
• Technology architecture (infrastructure services and the technology).

The diagram below shows a high level view of the TOGAF’s Architecture Development Method (ADM).

  

Note how Requirements Management is at the center of the process and indicates that the ADM is continuously driven by the requirements management process.  Requirements Management is the glue that holds all of the other processes together. It is important to understand that the Requirements Management balloon does not represent a static set of requirements.  Instead, it represents a dynamic process whereby requirements for enterprise architecture and subsequent requirement changes are identified, stored and used by all other ADM phases. The ability to deal with changes in requirements is crucial to ultimate success. Architecture is an activity that is driven by constant change as the business changes to address competitive challenges, economic swings, regulatory changes, and mergers and acquisitions.

TOGAF does not mandate or recommend any specific requirements management process or tool. It simply states what effective requirements management should be.  The Enfocus Requirements Suite™ from Enfocus Solutions is one of the few requirements management tools on the market that responds to the TOGAF requirements management process. The Enfocus Requirement Suite™ allows requirements to be captured by business process and IT service components (application, data, and infrastructure), has powerful change management capabilities and keeps a history of all requirement changes made to the processes or IT service components.  To find out how Enfocus Requirement Suite™ could help your organization, please download our fact sheet below.

Innovating using Social Technologies

CIOs and business units are struggling to decide how and to what extent to use social technology in their businesses, even though it offers considerable promise.   A key reason is that a majority of social media outside the enterprise is just pure communication. Organizations have struggled to see how applications such as Facebook or twitter can provide tangible benefits to the organization. Also, employing these tools inside the enterprise imposes additional complexity and challenges on already overwhelmed staff.  Social technology must be woven into the existing IT fabric so as to help users gain efficiencies in business processes, access key information for decisions, and capture knowledge that can be managed and shared with others.

To gain enterprise acceptance, social technology, like any other enterprise software proposition, needs to have business drivers. However, unlike many applications that provide tangible process efficiencies apparent to everyone, social technology benefits are often seen as a bit “squishy.”  Younger generations inherently know the benefit of social technologies, but clearly some education of senior leadership and business stakeholders may be needed to earn their buy-in to the benefits of social technologies. In doing so, it is important to highlight a number of tangible benefits made possible by social tools.

• Staying Connected - Social networking provides an easy way to stay in touch with co-workers, customers and suppliers.  During 2011, there were more Facebook messages sent than there were emails.  People feel more connected and informed with social media than with many other methods of communication.
• For means of communication – Social technology provides an excellent mechanism for communicating.  It is seen by many people as being far superior to email, telephone, direct mail, etc.  Think about the last time a teenager or college student returned an email?
• Achieving a more personal connection-Having a social networking profile allows you to keep informed on recent happenings with people in your network. You can discuss events with your co-workers and feel like you know them even though you have never met in person.  This is very important of large global teams.
  • Conversations—Social technologies can trace an online conversation in ways that e-mail can not.  In many cases it can replicate what formerly took place in physical meetings. Displacing a number of physical meetings with a more reproducible and traceable replacement extends the value of the meetings and can offer significant cost reductions.
  • Knowledge Management – Knowledge management has been difficult to implement for many organizations.  It is best practice to capture and share knowledge as an integrated part of the process.  In the past, conversations took place on phone calls or not at all and were seldom documented.  Social technology enables this injection of new insights in real time and can help with results adoption.
  • Embedding collaborative capabilities into existing applications or suites— Social technologies should be integrated into workflows bringing collaborative potential to where employees are working.  Providing this support for strategic processes will likely bring more support and endorsements from senior management. We are starting to see this in applications such Salesforce.com’s Chatter and SAP’s SmartStream.
  • Richer User Experience - Organizations need to move away from siloed information by providing richer and more relevant context for human-computer interactions.  Social identity becomes an additional means of navigation, relevant to both search software and end users. Conveying this capability to a range of stakeholders including data, content, and knowledge management groups as well as business units will be important.

A great opportunity to plan and coordinate how to initiate social technologies into your enterprise is to implement the Enfocus Requirement Suite.™ The Enfocus Requirement Suite™ from Enfocus Solutions was designed from the beginning to utilize social technologies. The goal is to create a community between various stakeholders and development teams working together on a project. The “community” is charged with developing a solution that meets certain business objectives.

Social technologies work very well for this type of situation as they allow people with different backgrounds such as marketing, IT, finance, and engineering and in different locations and cultures such as US, Europe, Asia, and South America to work together on a common goal.

Implementing a SaaS tool such as the Enfocus Requirement Suite™ is great step in moving towards implementing social technologies in the enterprise. The product allows a project community to be established between project stakeholders and the development team. The stakeholders and the development team may be scattered geographically.  This is important as stakeholders are often geographically dispersed and it is also common for development to be geographically because of outsourcing.

The Enfocus product allows the community to work together to develop requirements, validate the requirements, and manage the requirements through the product lifecycle from design to deployment. The community is kept informed of changes to the requirements and can work together on elaborating on requirements to ensure they are understood and achieved.  Developers and stakeholders may post questions and comments about requirements. Requirements may be further elaborated with visualization methods such as process flows, UML diagrams, mind maps, videos, etc. All of the applicable attachments are available for the community to view. Requirements are grouped together into bundles to support development iterations. The bundles include structured requirements with related needs, comments, visualizations, and the like..  There are fun features to encourage participation such as “Like” and “Dislike” buttons and flexible commenting.

Using a tool such as the Enfocus Requirement Suite™ is ideal for introducing social media technologies for a variety of reasons. First, it possible to start small by focusing on a single project.  Using lessons learned from the single project, the tool may be expanded to the enterprise. Since the product is subscription based, organizations can start small and expand as needed.

The Enfocus tool is process focused and provides collaborative and social technologies for requirements development and management processes. Additional communications and collaboration technologies are hard to justify unless they are used in context of a business process.  The product is a cloud based application and may be accessed from anywhere using a web browser whether on a tablet or a computer. This provides a simple way to introduce cloud computing applications to the organization. The tool provides knowledge management for objects such as business rules, business processes, IT services, and stakeholders are captured and updated as part of the process and can be shared with other project communities.

The RequirementCoach™ component of the Enfocus product provides many example requirements and practice aids that teams may use to improve business processes, define requirements for cloud computing, define requirements for social networking, and so on. These example requirements and practice aids help significantly in evaluating and implementing social tools.  The RequirementCoach™ provides example requirements of how to integrate social technologies with business process management, workflow, knowledge management, and business analytic applications. Obtaining this knowledge from a consultant can cost tens of thousands of dollars.  Project communities could use these example requirements to introduce social technologies to other key processes such as CRM, human resources, finance, product design, and the like.

Agile Business Processes or Digital Concrete?

The best-of-breed vs. integrated suite has been an ongoing battle since integrated ERP software suites were first introduced. In the early days, buyers were forced to choose between multiple standalone systems that performed single functions very well or one integrated system that offered modules for most functions, but with varying degrees of functional depth. Over time, however, the functional gaps between best-of-breed offerings and integrated suites has narrowed. However as business models are beginning to change rather rapidly, the gaps are starting to widen again as smaller more agile vendors are able to focus on best of breed software for key processes with high rewards and quick paybacks.  Software as a Service (SaaS) offerings are also threatening traditional business models.

Large expenditures for ERP software solutions may be a thing of the past.  For most organizations, there is stiff resistance against long-term and high-cost ERP maintenance contracts.  Companies typically spend 16-22% of their software license fees on maintenance and support each year. This maintenance cost is becoming too high for many organizations as they look for other alternatives.  Some organizations have simply cancelled their software maintenance contracts while others have sought alternative support mechanisms.  However, these strategies are not advised and together present many risks for an organizations, including, among others:

• Inability to upgrade the software
• Lack of support for critical situations
• Difficulty in supporting changes in business processes without new software functionality
• Proliferation of workarounds, and
• Conflicts with other contractual arrangements

The cost of upgrading ERP software to current versions is extremely high, often in the millions or tens of millions of dollars, especially if the package has been customized, so software upgrades are often delayed.  Delayed software upgrades prevent organizations from taking advantage of new functionality offered by the vendor. There is no doubt that ERP upgrades are painful, expensive experiences. Forrester Research's Paul Hamerman, recently stated that this is why "most businesses and IT execs put off upgrades as long as possible to avoid costs and minimize business disruption." Aberdeen's ERP research states that upgrades are typically performed every 3.5 to 4 years. Budget, time constraints, and lack of business value are the top reasons given for delaying upgrades.

Unfortunately, its often the case that companies find themselves falling behind their  competition, and the need to upgrade becomes essential. When an organization finds that they cannot easily change business processes  because of lack of software functionality or falling behind the competition, because the cost of software upgrades and maintenance is so high, they often see their ERP systems as “digital concrete.”

Many organizations are evaluating SaaS cloud based solutions as an option. With SaaS, upgrades are usually much easier and sometimes automatic. Releases are usually delivered more frequently than on-premise packages. All SaaS customers are generally upgraded to new features because of the multi-tenancy nature of SaaS. Lower implementation and maintenance costs and the ability for the business to take advantage of new software features are compelling reasons for organizations to consider a SaaS solution.

If your organization is considering SaaS solutions or moving away from large ERP systems for specialized functions such as CRM or Supply Chain Management, then you should consider the following:

• Requirements Management – Defining good requirements is absolutely essential for any software implementation, development or improvement project. Incomplete and inaccurate requirements are a major cause of project failure.  Organizations should consider a tool such as the Enfocus Requirement Suite™ from Enfocus Solutions Inc. to allow business and IT stakeholders to collaborate and define clear requirements that deliver business value and address people, process, and technology issues.
• Master Data Management – Moving to a best of breed application or to a SaaS application will almost certainly create a master data management problem. Proactively managing master data is critical to achieving improved business performance in today’s highly competitive environment.  Data that evolves independently becomes error-prone and keeps decision makers from having a unified view of the data. It also prevents internal customers from obtaining accurate and timely information they need to make accurate decisions.  The result is higher costs, missed sales opportunities, eroding margins and increased risk. Master data management issues should be considered from the beginning.
• Cloud Integration – Many technologies, such as Dell Boomi Atomsphere, Jitterbit, and IBM CastIron Omni Connect are beginning to emerge that allow cloud based applications to be seamlessly integrated with on-premise applications. These technologies often use a graphical “no-coding” approach to integration which accelerates and simplifies the configuration and management of moving data to and from the Cloud.
• Business Process Management  - BPM Software is used for managing business processes while connecting people and applications. BPM Suites generally provide a platform for enterprises to tap into the power of mobile, cloud and social technologies to drive high-value business process improvement across the enterprise, through the supply chain, and out to customers. BPM software can make business process more efficient and can overcome many of limitations of traditional ERP systems.

Requirements for Mobile Computing (Part 1)

 

 

A mobile workforce improves productivity by enabling employees to engage with customers, coworkers, suppliers, and partners face to face and in real time. When employees leave their laptops in the office, they expect mobile applications to provide the same level of access to ERP and CRM applications, customer data, product information and workflow support pertinent to their jobs as they have in the office.  They want to access this information through Web 2.0 applications or mobile applications developed for mobile phones or tablets.

Mobile computing is fast becoming essential for many organizations to remain competitive. Let’s take retail for instance. Retail stores must now accommodate the technology preferences of tech-savvy consumers that want to shop and compare prices from their smartphones and tablets.  These sophisticated consumers find product information, promotions and prices from competing stores by scanning UPC codes when they are at the store. Retailers that adapt to how these consumers prefer to shop and, further, offer special applications that can be accessed through mobile devices will gain a competitive advantage over retailers that don’t.

IT organizations realize that they must boost the productivity of mobile employees while minimizing associated support costs. However, not everyone knows where to start building an enterprise mobile strategy—a big problem because mobile computing is driving user behavior, and to remain competitive, businesses must enable employees to communicate and share data on the move.  To get started, it is best to start with an enterprise mobility strategy. An enterprise mobile strategy helps address an organization’s strategy, requirements and approach for mobile computing.  The strategy should focus on three key factors:

1. Identifying and addressing user needs,
2. Integration with existing IT applications and data, and
3. Providing innovation to improve business processes.

A thorough Enterprise Mobility Strategy should provide a roadmap to deliver improved productivity, reduced capital and operating expenditures, and increased strategic agility to maintain a competitive advantage.  In formulating the strategy, the following questions should be answered.

• Who will need to access IT services through mobile devices (employees, customers, suppliers, partners)?
• What are user requirements and expectations for mobile computing?
• How do employees want to use mobile computing to improve productivity, increase customer satisfaction, and increase sales?
• What IT services do the users need to access (email, CRM, ERP, etc.)?
• What devices should be supported?  Should more focus be placed on smartphones or tablets?  What platforms should be supported?  Is it truly necessary to support ios, Android, Windows Mobile, etc?
• Should employees be issued a smartphone or should they provide their own?
• Should employees be provided an allowance to encourage adoption? If the devices are owned by corporate, what are the applicable asset management policies?
• What security policies and mechanisms need to be in place to protect data and services?
• How will IT provide user support for issues such as bugs correction, data integration, security administration, governance, change management, and operations management?
• Which applications need to be mobilized? Which should receive priority?
• How will corporate branding and user experience issues be addressed in application design? 

In future articles, I will address how to go about eliciting needs for mobile computing, so pleased check back often.  Please download our product fact sheet to find out how the Enfocus Requirement Suite™ can be used to help you define your enterprise mobile strategy, prioritize your mobile applications portfolio, or define requirements for a mobile application.

Writing an Effective Problem Statement

According to Wikipedia , a problem statement is a concise description of the issues that need to be addressed by a problem solving team and should be presented to them (or created by them) before they try to solve the problem.

In project management, the problem statement is part of the project charter and defines what the problem is so that they the project team and stakeholder can focus their attention on solving the problem. It is important to have a good problem statement before starting eliciting requirements for a solution. A good problem statement should answer questions such as:

• What is the problem?
• Who has the problem?
• Where does the problem occur?
• When does the problem occur?
• What does the problem impact?

A good problem statement should be:

• Concise. The essence of your problem needs to be condensed down to a single sentence. A reader of the project statement should be able to say “Aha!! Now I now understand the problem.”
• Specific. The problems statement should focus your thinking, research, and solutions toward a single population or issue.
• Measurable. Problems can be measured in terms of degree and frequency. The strongest problem statements incorporate measurable aspects of both the degree and frequency of the problem as it exists.
• Specify what is Impacted. The problem statement should identify the population affected by the problem.

Let’s examine the steps for creating a good problem statement.

• Write down your problem or current state. Don’t worry too much about quality at this point – simply making a start is significant.
• Expand on the problem by asking the following questions:
• Who does it affect / does not affect?
• What does it effect / does not affect?
• How does it effect / does not affect?
• When is it a problem / is not a problem?
• Where is it a problem / is not a problem?
• Re-write your problem statement based on those answers. It may consist of several sentences or a set of bulleted items.
• Try to revise the bulleted list or initial problem statement into a single clear sentence. This might take a couple of attempts but stick with it. Finally, review your new problem statement against the following criteria:
• Focused on only one Problem.
• One or two sentences long.
• Does not suggest a Solution.

You should now have a concise and well balanced Problem Statement ready for a brainstorming session. It should be unambiguous and devoid of assumptions. It will enable you or your group to focus in on the problem and provide the foundation for the team to begin work toward solutions that truly fit.

Creating a Business Case for a Software Project

Early in most software development projects, business analysts are often asked to create a business case. A business case is used to document the business benefit and provide justification for the project and is used to support the related funding request for the project.  In this blog post, I will discuss the typical components of a business case.

A business case compares the estimated resources, schedule and costs of a project with the benefits that it is expected to provides. The business case must show that the benefits outweigh the costs. In many instances, it includes a financial analysis that calculates the project’s return on investment (ROI) or the Net Present Value (NPV).

The benefits of a business case are specified in increased revenue and reduced costs. For example, a business case for producing a new product would include the anticipated increase in revenue from sale of the product. Although financial information is important, a business case is more than a financial justification for a project. It is business justification and will often include other benefits such as:

• Strategic advantage
• Corporate image an brand loyalty
• Increase in market share
• Business agility
• Reduction in cycle times
• Process efficiencies
• Improvement in customer satisfaction
• Employee loyalty and recruitment

A business case generally includes the following components:

Executive summary highlights the key points in the business case. These include important benefits and the return on investment.

Project background provides relevant information so that the people who must approve the business case can decide whether the project is both viable and worth doing. If a project involves complicated technologies, the audience may not believe the financial analysis until it understands how the technologies enable the benefits.

Business opportunity describes the motivation for the project that the business case will propose. The business opportunity includes a definition, a statement of scope, and a discussion of objectives that the project will help the organization achieve.

Alternatives are analyzed for the proposed project. For example, an online learning business case might compare the benefits and costs of classroom learning. All business cases involve at least two alternatives: doing or not doing a project.

Costs describe the resources for undertaking the project and their monetary value.  The costs should include the cost of development, implementation, training, change management, and operations.

Benefits describe the projected financial benefits from undertaking the project.  Benefits are usually presented in terms of revenue generation and cost reductions.

Financial analysis compares benefits to costs and analyzes the value of a project as an investment. The analysis may include a cash flow statement, return on investment, net present value, internal rate of return, and payback period.

Other benefits describe other expected benefits that cannot be quantified in terms of dollars and cents.

Assumptions are events that a business case anticipates will happen. For example, a business case might assume approval from a regulatory agency. Critical assumptions must occur for a project to succeed.

Constraints are schedule, resource, budget, staffing, technical, and other limitations that may impact the success of a project. For example, a project might require that all employees have access to a central database.

Organizational considerations examine how a project impacts an organization. A project’s success might depend on management support and employee acceptance.

Risk analysis evaluates the probability that a project can be implemented successfully and the risks involved in undertaking the project. Risks also may result from not undertaking the project.

Moving Forward explains how the project should be developed and implemented. This is usually explained in terms of phases and tasks. This section also offers suggestions on how to proceed.

The Enfocus Solutions Requirements Suites™ provides convenient the framework, tools, and repositories to store and share these methods for assembling a business case so the documentation is available throughout the project to ensure complete understanding by users, stakeholders and developers.

Requirements and Various Stakeholder Groups

You might have noticed that requirements activities on projects sometimes lead to adversarial relationships. Customers don't always feel that business analysts have their best interests at heart. Product managers get frustrated when customers demand never-ending changes in requirements but don't want the delivery date to slip. Testers don't appreciate having to redo their work because no one told them about updates to the requirements. Developers bristle when the project manager holds their feet to the fire to meet schedule despite piling on new features through scope creep. It's a wonder anyone still speaks to their colleagues at the end of the project.

If you're interested in pursuing better requirements processes, you have to respect the many cross-connections between the software development group and numerous external stakeholders. This article identifies some of those important interfaces and suggests ways to engage such stakeholders in a collaborative approach toward more successful projects in the future.

Figure 1 shows some of the project stakeholders that can interface with a software development group and some of the contributions they make to a project’s requirements engineering activities. Explain to your contact people in each functional area the information and contributions you need from them if the product development effort is to succeed. Agree on the form and content of key communication interfaces between development and other functional areas, such as a system requirements specification or a marketing requirements document. Too often, important project documents are written from the author’s point of view without full consideration of the information that the readers of those documents need.

Figure 1. Requirements-related interfaces between software development and other stakeholders.

On the flip side, ask the other organizations what they need from the development group to make their jobs easier. What input about technical feasibility will help marketing plan their product concepts better? What requirements status reports will give management adequate visibility into project progress? What collaboration with system engineering will ensure that system requirements are properly partitioned among software and hardware subsystems? Strive to build collaborative relationships between development and the other stakeholders of the requirements process.

When the software development group changes its requirements processes, the interfaces it presents to other project stakeholder communities also change. People don’t like to be forced out of their comfort zone, so expect some resistance to your proposed requirements process changes. Understand the origin of the resistance so that you can both respect it and defuse it.

Much resistance comes from fear of the unknown. To reduce the fear, communicate your process improvement rationale and intentions to your counterparts in other areas. Explain the benefits that these other groups will realize from the new process. Make sure they understand the pain that projects have experienced in the past because of shortcomings in your current processes. The prospect of eliminating pain is a great motivator for change. When seeking collaboration on process improvement, begin from this viewpoint: “Here are the problems we’ve all experienced. We think that these process changes will help solve those problems. Here’s what we plan to do, this is the help we’ll need from you, and this is how our work will help us both.”

Here are some forms of resistance–both active and passive—that you might encounter:

• A change control process might be viewed as a barrier thrown up by development to make it harder to get changes made. In reality, a change control process is a structure, not a barrier. It permits well-informed people to make good business decisions. The software team is responsible for ensuring that the change process really does work. If new processes don’t yield better results, people will find ways to work around them—and they probably should.
• Some developers view writing and reviewing requirements documents as bureaucratic time-wasters that prevent them from doing their “real” work of writing code. If you can explain the high cost of continually rewriting the code while the team tries to figure out what the system should do, developers and managers will better appreciate the need for good requirements.
• If customer-support costs aren’t linked to the development process, the development team might not be motivated to change how they work because they don’t suffer the consequences of poor product quality.
• If one objective of improved requirements processes is to reduce support costs by creating higher-quality products, the support manager might feel threatened. Who wants to see his empire shrink?
• Busy customers sometimes claim that they don’t have time to spend working on the requirements. Remind them of earlier projects that delivered unsatisfactory systems and the high cost of responding to customer input after delivery. You’re going to get the customer input eventually. It’s a lot cheaper and less painful (and people are in a better mood) to get it earlier rather than later.

Anytime people are asked to change the way they work, the natural reaction is to ask, “What’s in it for me?” However, process changes don’t always result in fabulous and immediate benefits for every individual involved. A better question—and one that any process improvement leader must be able to answer convincingly—is, “What’s in it for us?” Every process change should offer the prospect of clear benefits to the project team, the development organization, the company, the customer, or the universe. You can often sell these benefits in terms of correcting the known shortcomings of the current ways of working that lead to less than desirable business outcomes.