Project Retrospectives to Improve Requirements

A project retrospective is a way to look back at events that have already taken place and identify and document lessons learned and other ideas that will in the future help managers increase the effectiveness of their teams. Regularly held retrospectives break the repetition of ineffective program and project management practices, provide the opportunity to solve immediate problems through rapid application of key learning, and increase the probability of affecting behavioral changes.

A Project Retrospective is no performed only at the end of a project. Team members should meet at strategic points throughout the project life cycles to discuss what is working and what needs to be improved. Retrospectives explore what is working well on a project and ensure that good practices are reinforced and repeated.  These key events might be

• Requirements Validation
• Design Review
• User Acceptance Test
• Deployment and User Training
• Project Completion

The intent of a retrospective is to capture key lessons learned during a project and apply improvements during the remainder of the life cycle.  During a retrospective, the team works together to create actionable plans to improve both effectiveness and efficiency.  The three goals of a project retrospective are:

• Review the project from a number of different perspectives.
• Capture and record specifics about what went well and what can be improved.
• Create an action plan for implementing changes that is outlined with tasks, deliverables, timelines, and owners.

To run a successful retrospective, first identify the objectives. A facilitator – who may be a professional from outside the organization, a team member, or the project manager – should be chosen. The facilitator should meet with the project manager and selected project team members to get a sense of what happened, to get relevant project data, and to understand the organization’s roles, responsibilities, and reporting relationships. This helps give a sense of the culture and to identify any important issues.

The facilitator’s role is to watch the process and guide the team by providing opportunities for all to be heard and to participate. The facilitator should also help the group work under guidelines that yield healthy human interactions, and be willing to work with emotions.

Retrospective attendees need to be identified next. A group of six to eight people is most effective. If there are more people working on the project, then several small retrospectives can be initiated to include everyone. The facilitator should create a safe space, an atmosphere where everyone feels comfortable talking openly about important issues. Food can help get team members talking.

A retrospective survey may also be helpful in running the meeting. Questions may include:

• What worked well?
• What did we learn from this project?
• What should we do differently next time?
• What don't we understand that needs to be clarified for the future?

Discussion at a retrospective should be recorded and analyzed. Once specific themes are identified, an action plan can be developed. Specific action items should be created and assigned to retrospective attendees. The information captured can then be reviewed with management in a summary report, and any documented good practices can be shared across the organization.

A project retrospective should not be held as an afterthought without a defined, objective process. If retrospectives are held after a project is over, then the lessons learned should be applied to the next program or project. The sharing of perspectives leads to the understanding of what worked well. The discussion identifies opportunities for improvement, and highlights lessons learned.

A retrospective helps the team see ways to work together more efficiently. With increased buy-in from the people performing the work, a higher probability of achieving sustainable and permanent change occurs.

The Business Value of Better Requirements

Not every manager is convinced that his team needs to do a better job on requirements development and management, or that such an investment will pay off. Numerous industry studies, however, indicate that requirements issues are a pervasive cause of project distress. The often-quoted CHAOS Reports from The Standish Group indicate that three of the biggest contributors to projects that fail or are “challenged” are lack of user input, incomplete requirements and specifications, and changing requirements and specifications.

An Economic Argument

The case for implementing better requirements practices is an economic or business argument, not a philosophical or technical position. Think about how your company’s bottom line is affected by requirements-related problems. Then use that understanding to justify investing in better requirements practices that can pay off for the long term..

A recent case study of requirements failure was the Federal Bureau of Investigation’s new case management software system, called VCF. This project was abandoned after $170 million had been spent because the delivered software was full of defects and off-target functionality. As one investigator wrote:

I suspect what happened with the VCF is that in the rush to put in place a system, you think you got your requirements nailed, but you really don’t. It was a classic case of not getting the requirements sufficiently defined in terms of completeness and correctness from the beginning. And so it required a continuous redefinition of requirements that had a cascading effect on what had already been designed and produced. (Goldstein, Harry. 2005. “Who Killed the Virtual Case File?” IEEE Spectrum 42(9): 24–35).

Numerous studies have examined the effects of errors in requirements on software projects. They consistently find that nearly half of the discovered defects originated as requirement errors. The typical outcome of errors in the requirements is an expectation gap, a difference between what developers build and what customers really need. Clearly, any domain that is the root cause of approximately half of the problems on software projects deserves our attention.

The main reason errors in requirements are so damaging is that they force the development team to perform extensive rework to correct the errors. It’s well-established that the cost of correcting a software error increases dramatically the later it is discovered, as shown in Table 1. An error, omission, or misunderstanding in the requirements forces developers to redo all the work they’ve already done based on the incorrect requirement. Therefore, any technique that can reduce requirement defects and prevent some of this wasted effort is a high-leverage investment indeed. One analysis of the potential return on investment from better requirements suggested that requirement errors can consume between 70 and 85 percent of all project rework costs.

Table 1. Relative Cost to Correct a Requirement Error

Stage Error Is Discovered	Relative Cost to Correct
Requirements Development	1X
Design	2–3X
Construction	5–10X
System or Acceptance Test	8–20X
Operation	68–110X

What Better Requirements Can Do for You

In addition to avoiding some of the negative consequences described above, better software requirements provide numerous benefits. These include selecting the right projects to fund, facilitating estimation, enabling rational prioritization, developing higher quality designs, and testing more effectively.

Selecting projects to fund. Good preliminary requirements enable senior managers to make effective business decisions as organizations decide which among a set of potential projects to fund. Better requirements allow more accurate projection of business returns. Once a project is funded, better requirements allow project managers to more sensibly partition tasks among their teams and even among individual team members.

Facilitating estimation. Well-understood requirements can help your team estimate the effort and resources needed to execute a project. Reliable estimation requires some historical correlation between requirements size and effort.

Enabling prioritization. Documented requirements allow the team to prioritize its remaining work. Most projects need to make compromises to ensure that they implement the most critical and most timely functionality. A prioritized requirements baseline helps the team incorporate those changes that will deliver the maximum customer value. One study revealed that just 54 percent of the originally defined features were delivered on an average project. If you can’t implement all of the requested functionality, make sure the team implements the right portion.

Developing designs. Requirements are the foundation for design. Therefore, well-understood and well-communicated requirements help developers devise the most appropriate solution to the problem. High-quality requirements also ensure that the development team works on the right problem. Many developers have experienced the frustration of implementing functionality that someone swore they needed, only to find that no one ever used it. One survey indicated that fully 45 percent of the delivered software product features were never used. Wasting less time implementing the wrong functionality accelerates the project and maximizes its business return.

Testing effectively. Well-defined and testable requirements allow testers to develop accurate test procedures to verify the functionality. Prioritizing requirements tells testers which ones to concentrate on first. Assessing requirement difficulty and risk helps testers know which functionality should receive the closest scrutiny.

Tracking project status. A comprehensive, traced set of requirements helps the stakeholders know when the project is done. A body of work is complete when all of the requirements allocated to it are either verified as being correctly implemented in the product or deleted from the baseline. Defined business requirements also allow the stakeholders to determine whether the project has met its goals.

Accelerating development. Believe it or not, investing more effort in developing the requirements can actually accelerate software development. This seems counterintuitive, but it’s true. Defining business requirements—the expected business outcomes the product will provide—aligns the stakeholders with shared vision, goals, and expectations. Effective user involvement in establishing the requirements reduces the chance that users will reject the new system upon delivery. Following are some published illustrations.

• In a study of 15 banking and telecommunications projects, the most successful projects spent 28 percent of their resources on requirements engineering, whereas the average project in the study devoted just 15.7 percent of its effort to requirements.
• Increasing the fraction of the total budget devoted to requirements on a group of NASA projects led to substantially lower overrun of both cost and schedules; see Table 2 (Hooks, Ivy F., and Kristin A. Farry. 2001. Customer-Centered Products: Creating Successful Products Through Smart Requirements Management. New York: AMACOM).
• In a European survey, the fastest project teams spent about twice as much of their schedule (17 percent versus nine percent) and effort (14 percent versus seven percent) on requirements activities as the slower teams.

Table 2 Cost and Schedule Overruns on Some NASA Projects

Percent of Budget Spent on Requirements	Number of Projects	Average Project Cost Overrun
< 5%	5	125%
5 to 10%	7	83%
> 10%	6	30%

Accurate requirements ensure that the functionality built will let users perform their essential business tasks. The requirements also establish achievable quality expectations. This lets the team implement both the capabilities and the product characteristics—the nonfunctional requirements—that will make users happy. Additionally, emphasizing requirements development is cheaper than relying on beta testing to find requirements problems. Fixing problems that late in the game is far costlier than correcting them earlier.

Requirements for The open Web (Part 1)

Open web is term being batted around to describe the movement of web technologies to open standards and technologies.  The move to Open Web has been gradual, but has now gained sufficient momentum that it will continue into the future. Open Web is more that just a set of technologies, it is also a community and a culture. Today’s web technologies such as HTML4, Adobe Flash, Microsoft Silverlight, Simple Object Access Protocol [SOAP] web services, Java EE, and .NET are gradually being replaced with open web technologies. While HTML5 is the best known, Open Web technologies also include JavaScript (client and server), CSS3, Representational State Transfer (REST), and mobile frameworks such as jQuery Mobile, among others.

Even though lack of support for Flash on the iPad severely damaged the Adobe Flash market, it appears likely that wide adoption of HTML5 will end Adobe Flash and Microsoft Silverlight for good. Even though at the moment HTML5 may not be as powerful as Flash or Silverlight for digital rights management or video streaming,  it will soon catch them. It is clear that HTML5 standards and technologies are advancing rapidly enough to drive the next evolution of cross-platform rich Internet applications

REST (Representational State Transfer ) is a set of principles that define how Web standards, such as HTTP and URIs, should be used. Adhering to REST principles will lead your organization to a broader, resource-oriented architecture and management platform. RESTful APIs are quickly replacing SOAP as the new standard. RESTful APIs embrace the five key REST principles listed below.

• Give every “thing” an ID
• Link things together
• Use standard methods
• Permit Resources with multiple representations
• Communicate statelessly

jQuery has been one of the most popular JavaScript libraries.  jQuery is a fast and compact JavaScript Library for rapid web development that simplifies HTML document traversing, event handling, animating, and Ajax interactions.  jQuery Mobile is a touch-optimized Web framework for smartphones and tablets. It provides a unified, HTML5-based user interface for popular mobile device platforms and is built on the solid jQuery and jQuery UI foundation. Expect to see jQuery Mobile as the new standard for mobile applications targeted at smartphones and tablets.

Cloud computing also plays a key part of the Open Web movement. Cloud platforms play a major role in Open Web because they level the playing field for Open Web developers and provide so many useful services for open Web applications. Most cloud computing applications use RESTful APIs, and support HTML5.

In future posts in this series, I will describe key issues that should be considered as requirements are defined for web and mobile applications. We provide example requirements for a variety of areas such as this in the RequirementCoach™ component of our Enfocus Requirement Suite™ product.  To find out more about the Enfocus Requirement Suite,™ please download our product fact sheet below.

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 (TOGAF)
• Federal Enterprise Architecture (FEA)
• NIST Enterprise Architecture Model
• Gartner Group

The two most used are probably the Zachman Framework and TOGAF. 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.