Migrating Applications to the Cloud: A Guide for PMs and BAs
Simply put, cloud computing is computing based on the Internet. In the past, people ran applications on a physical computer or server in their building, cloud computing allows people access the same kinds of applications more easily and anywhere through the Internet. Cloud computing is growing rapidly because it just makes economic sense. So why are so many businesses moving to the cloud? It’s because cloud computing increases efficiency, helps improve cash flow and offers many more benefits. Let’s explore some of these benefit:
Automatic software updates
Many organizations that have implemented an on-premise ERP or CRM system know how painful it is to upgrade the software. With Cloud computing, updates are applied automatically — this is part of the basic service and often saves organizations millions of dollars per year. This frees up customers’ time that can be used on other important tasks.
Flexibility
The Cloud provides much more flexibility for increases and decreases in demand. For example, if a company needs more bandwidth than usual, maybe for some special promotion, a cloud-based service can instantly meet the demand because of the vast capacity of the services’ remote servers. In fact, this flexibility is so crucial that 65% of respondents to an InformationWeek survey said “the ability to quickly meet business demands” was an important reason to move to cloud computing. New users can be added or removed very easily adjusting to business demand as needed.
Disaster recovery
Disaster recovery is often much easier for cloud based services as this capability is a standard part of the service. Cloud computing providers take care of most issues, and they do it faster. Aberdeen Group found that businesses that used the cloud were able to resolve issues in an average of 2.1 hours, nearly four times faster than businesses that didn’t use the cloud (8 hours).
Services can Be Paid with OpEx
Cloud computing services are typically pay as you go, so there’s no need for capital expenditures. Because cloud computing is faster to deploy, businesses have minimal project start-up costs and predictable ongoing operating expenses.
Increased collaboration
Cloud computing increases collaboration by allowing all employees – wherever they are – to sync up and work on documents and shared apps simultaneously, and follow colleagues and records to receive critical updates in real time. A survey by Frost & Sullivan found that companies which invested in collaboration technology had a 400% return on investment. Cloud infrastructures generally have much better capabilities to accommodate global scaling and often have significant latency in Worldwide deployments than internal corporate networks.
Mobility
Let’s face it, people want access to IT services no matter where they are. For example, someone might be in Peru on vacation and need to process and approve transactions in the United States. Running applications in the cloud enables people to work from anywhere. All employees need is to have Internet access, which is widely available across the world. Many people now from home or work remotely in various places; Cloud computing enables this.
Security
One of the serious concerns about the Cloud is about Security. However this does not seem to be as serious as the hype put out by IT departments. Most corporate IT departments are nowhere near sophisticated or have the resources or experience that Cloud vendors do in this area. In reality, major cloud vendors (IBM, Amazon, Microsoft) are far more sophisticated and have much better understanding and resources of security than corporate IT departments.
Some 800,000 laptops are lost each year in airports alone. This can have some serious monetary implications, but when everything is stored in the cloud, data can still be accessed no matter what happens to an individual laptop.
Agility
Implementing a SaaS application is much quicker than implementing traditional software applications. SaaS applications can often be provisioned and available the same day. Users can often start productive work within days not months. There is no hardware to buy, desktop software to deploy, or complex implementation issues. Users can often start training through online video classes and practice using the system in a sandbox.
Organizations seeking to move applications into the Cloud have three primary options:
- Rehost on infrastructure as a service (IaaS),
- Rebuild on platform as a service (PaaS), or
- Replace with software as a service (SaaS)
Let’s explore each of these options:
Rehost – Rehosting involves moving the application and its components residing on internal corporate servers to servers hosted in the Cloud. Rehosting an application without making changes to its architecture can provide a fast cloud migration solution. However, this may not always be the best method. It may be better to also make some architectural changes to take advantage of improved security, scalability, and business continuity when moving applications to the cloud.
Rebuild – Rebuilding the solution means discarding the existing solution and rebuilding the solution using software and tools provided by Platform as a Service. One of the major PaaS vendors is Force.com. Force.com provides a complete environment for quickly building new applications. Using Force.com makes a lot of sense when you are using Salesforce.com as your CRM and you have additional applications that need to interface with it. It is often easier, faster, and cheaper to rebuild the applications in Force.com instead of trying to integrate legacy applications with Salesforce.com.
Although rebuilding requires development of new skills and loss of knowledge of existing code and frameworks, the advantage of rebuilding an application is access to innovative features in the providers’ platform. PaaS can significantly improve developer productivity, allowing teams to deliver solutions faster than they could with the old legacy code that they maintained before.
Replace – Replacing an application involves replacing an existing application (or set of applications) with commercial software delivered as a service. This option avoids investment in mobilizing a development team when requirements for a business function change quickly.
A new tool that can really help with migrating application to the cloud is offered by Enfocus Solutions. First, the tool is a SaaS based offering and ready for immediate use. Next, it provides many capabilities to help with difficult decisions of migrating applications to the cloud such as:
- Documenting business processes
- Documenting problems and opportunities for improvement in processes
- Documenting legacy applications that support the business processes
- Documenting and analyzing whether applications should be rehosted, rebuilt, or replaced
- Defining nonfunctional requirements for IaaS and PaaS
- Defining functional requirements for SaaS
- Defining transition requirements for moving to the new application
- Performing fit/gap analysis of SaaS vendors
- Measuring Business Outcomes
Overall the tool from Enfocus Solutions provides an excellent method for defining and managing your cloud migration strategy.
[cta id=”7436″]
Collaboration: Easy to Talk About, Much Harder to Achieve (Part 1)
We’ve all heard about collaboration, talked about collaboration, and probably even agreed that collaboration is really really really important—problem is, it seems much easier to talk about than to actually achieve.
One of the key roles a product manager can play in any organization is to bring people together—to bring customers and users together to understand what their problems are and how to best solve them, to bring internal stakeholders together to understand what products will best serve the organization, and to bring the individuals of a product team together to work synchronously towards launching a valuable product that will delight their market and upset their competitors.
But the fact is, it’s really challenging to get people harmoniously working together—and just as hard to keep them doing so throughout the entire product development lifecycle. As humans, we are all inclined to fulfill our own needs first—but when it comes to collaboration, those inclinations need to be shifted towards each individual working to fulfill the needs of an entire team before their own. If you’re thinking it sounds like hard work then you’re right—fostering collaboration during the product development lifecycle is indeed hard work.
But it’s hard work that pays off.
It’s currently estimated that 70-90% of all new products fail. You wouldn’t be alone if your initial reaction to that number is ‘wow!’ It seems like too high of a number—and one that makes launching a new product seem like a pretty bleak undertaking.
But if we look at the leading cause of failing products then we might see that there is hope for a solution: the number one reason products fail is because market needs are not understood and a solution is defined before understanding what the real problem is.
You might recognize a few symptoms that result:
- You seem to be operating within a ‘reactive’ product development environment—when you’d much rather be operating within a strategic one.
- Keeping up with the competition seems like a furious and constant battle.
- Your company keeps launching new features but your customers don’t seem to be using them all that much.
- The number of products returned is far higher than expected.
- A backlog of features is piling up higher and higher with what feels like no real direction on what to do with them.
- You’ve forgotten what the voice of the customer sounds like within the chaos.
The key to understanding the market problem is to make sure that the right amount of time is being invested in doing so—and that it is being done collaboratively. When you rely on only one or two people—or even just your market alone—to define what the market problems are, the risk of missing the underlying cause rises significantly. Time needs to be invested in analysis and understanding of the market evidence.
As the complexity of products increase, so does the need for collaboration.
As consumers ourselves, we’ve all noticed how the complexity of products has increased over the years. The basic cell phones we used to carry around with a screen barely big enough to read a single text message have evolved into smart phones with screens three times the size and more features than we can even name or use (especially when you consider what most of them do to battery life!).
Now, couple that increase in functional complexity with the current level of competition in most markets—and what you’ve got most times are companies constantly rushing to launch new features or products just to try and stay in the game. Problem is, they are starting to forget about what the actual problem is they are trying to solve with all these releases—or if they are even solving one at all. According to the Standish Group’s 2013 Chaos Manifesto report, it’s estimated that only 20% of a product’s features are used often. Yes, only 20%. The rest are hardly ever used (50%) or used infrequently (30%). When you start to translate the time and resources it takes to develop that 80% of features never or infrequently used—well, it certainly makes you stop and think how your company could better be spending their time and money.
One of the largest challenges companies have in today’s market is the constant pressure to release new features and products quickly in order to keep up with the innovation being driven by technological advances. It goes without question that with the constant pressure and increasing functional complexity of products, the processes to develop the products also becomes more complex. More people are involved in the development of the product, teams are spread out in different geographical areas, and there is an exponentially greater risk that the product team will fall out of sync with one another and end up with a product that does not solve any real market problems, or if it does—it’s taken longer than the competitor to release it.
To keep up with the pace of the market and complexity of products, product teams need to work collaboratively now more than ever. Without the synchronicity that collaboration drives, there is simply too much time lost in the product cycle to stay ahead of the competition.
What do you do to make sure your team is in sync with one another? What are some of the problems that you face trying to enable collaboration on your teams?
Next week, we’ll post a second blog in this collaboration series that explores the collaboration conundrum furthers and looks at what the key activities and opportunities are for collaboration during the product discovery and delivery phases of a project.
Read Part 2: Collaboration – Working together through Product Discovery
[cta id=”7443″]
A Dire Warning for Business Analysts
In the most recent VersionOne State of Agile Survey released in 2014, Business Analysts are considered the least knowledgeable about Agile. Please see the diagram below.
Working with many Business Analysts, I am not surprised by this statistic, but it does concern me. In the Scrum world, there is no official role for a Business Analyst. We don’t write the functional requirements the way we did in the past and a Business Analyst is not required or needed to write or draft user stories. Business Analysis skills are very much needed, however the traditional BAs that simply write functional requirements will either need to re-skill or retire.
Recently Forrester research shows that more than 90% of organizations are actively pursuing Agile. If Business Analysts do not learn and embrace Agile now, and they plan on continuing writing functional requirements in the ways they have in the past, then they should start planning a new career as their positions will soon be eliminated in a future downsizing effort. If the BAs in your organization have not made the transformation to Agile, please call us at Enfocus Solutions; we can help. We can provide you with the education, knowledge, and tools to transform you business analysis function to the Agile world. Please attend the Webinar tomorrow to find out more.
[cta id=”7436″]
The CIO/CMO Divide: A Guide for Project Managers and Business Analysts
Lately, Marketing has been purchasing a significant amount more of marketing-related technology and services using their own capital and expense budgets. Some of this purchasing is being done outside the control of the internal IT organization and some is being done in conjunction with IT. Gartner has made the bold prediction that by 2017, the CMO will spend more on IT than the CIO.
Let’s look at some of the facts from the Gartner 2013 US Marketing Spend Survey:
- The average percentage of revenue spent on marketing is 10.4 %
- Digital Marketing represents 1/3 of Total Marketing Spend
- Up to Half of all Digital Marketing is Outsourced
- Search Marketing topped the CMO’s list of Outsourced Activities
- Over 40% claim that the keys to Marketing success are 1) Corporate Web Site, 2)Social Marketing, and 3)Digital Advertising
Now, let’s look at some trends of why marketing is spending more and more on technology. First, we are living in the age of the customer. Customers now have real-time information about pricing, product features and competitors. As a result, they hold the advantages, and one of the few competitive advantages remaining for businesses is to concentrate on the knowledge of and engagement with customers. Josh Bernoff, a Forrester Research analyst stated in a recent report that companies must not only be customer focused, they must be customer obsessed, focusing their strategy, energy, and budget on processes that enhance knowledge of engagement with customers. Implementing a customer based strategy falls under marketing for most companies.
For the last 10 years, many organizations focused on Customer Relationship Management (CRM). Now the focus is on marketing automation. We are seeing many entrants in this market with solutions offered by Hubspot, Marketo, Salesforce Pardot, Oracle Eloqua, and Act-On. Much of this is driven by the rise in popularity of social media sites, mobile applications and other web-based tools. Marketing departments are now beginning to monetize ongoing consumer conversations using social media monitoring tools provided by companies like Hootsuite, SDL, SproutSocial, and Radian6. The social media opportunity is huge and even traditional IT companies such as HP have recently joined in. The number of players and the amount of noise in this area is growing rapidly.
Another key trend is the use of big data for marketing purposes. Data analytics and business intelligence allow marketing to sort through the noise of customer data to gather the right information that is needed for product innovation, advertising, and much more. The correct customer data provides marketers with what they need to not only understand customers have done, but to predict what they will do.
The vast majority of marketing applications are provided as cloud services. Most cloud services can be paid for using OPEX funds, allowing Marketing departments to purchase key applications services and completely bypassing IT investment governance.
Marketing is a major player in the push for Bring Your Own Device (BYOD). Marketers want to use various mobile computing devices; many are designers and are demanding to use Apple computers. If they do not get the support of IT, they simply bypass IT and do it anyway. IT may object, but you can guess who wins when the decision goes to the CEO. BYOD frustrates IT for many reasons; they do not like losing control of the desktop and the devices attached to the network. However, many IT departments have received mandates and have been tasked with making the enterprise Apple-friendly (and increasingly Android friendly) and to adopt to a number of other devices such as tablets and tv media devices. BYOD in combination with a diminishing IT budget and cheap enterprise hardware and software deals has resulted in an IT department that is lagging and no longer the innovator that they were considered to be in the past. Many IT departments have even been accused of holding their companies back and placing their organization at a competitive disadvantage. Once involved and heavily invested in by the C-suite, the CIO has now taken a back seat to the CMO, as consumers are driving what tech products and services they want at home and in the workplace. CIOs must now accept this trend or look for another job.
Marketing has been traditionally underserved by IT. Because of the lack of marketing domain knowledge in IT, many CMOs have hired their own CTOs to guide their technology strategies. The tension between marketing and IT is actually quite natural given the way most organizations are structured. IT and marketing simply have different incentives and priorities. IT is primarily concerned with stability, security, cost, standardization, and functional specs, whereas marketing is more concerned with speed, agility, innovation, market impact, differentiation, and customer experience. It’s not that IT doesn’t appreciate marketing’s priorities — or vice versa. It’s just that their incentives cause them to value their own respective priorities more.
According to a new study by Accenture Interactive, 60% of CMOs and 73% of CIOs say that technology is essential to marketing in the evolving digital landscape. Furthermore, 77% of CMOs and 56% of CIOs rank each other’s departments as part of the top five business units with which they need to collaborate. However, according to the same survey, only one of every ten executives surveyed believe the CMO-CIO relationship and collaboration is at the right level. If you are a project manager or business analyst in IT, encourage your CIO to more closely collaborate with the CMO. Ask to work on IT marketing projects and you will have a bright future.
[cta id=”7436″]
Business Analysis and Project Management Trends in 2014
Normally, trends and projections come out in December or January. These are a little late, but at least they still make the first quarter in 2014. Here are my predictions of key trends that we will see affect business analysis and project management in 2014.
1. Agile Continues to Grow – Agile adoption will continue to grow. This will mean many changes in terms of how requirements are developed and managed. Requirement “shall” statements will be replaced with user stories. The three C’s model of users stories: Card, Confirmation, and Conversations will continue to grow. PMs and BAs will continue to redefine their roles in the agile world of self-managing teams and product backlogs.
2. Managing Data not Documents – As agile adoption continues, the need for large paper based requirement documents will go away. Requirements will be managed as data in a backlog, not as long paper-based business requirement documents (BRDs) or Functional Requirement Specifications (FRS).
3. Dual-Track Agile Takes Off – Agile will be difficult and a cultural challenge for many organizations where there are multiple teams and resources are not collocated. “User story hell” will become a reality for many organizations as teams continue to spend more and more time grooming the backlog. Many organizations will adopt dual-track agile or some variant to better manage discovery activities. This will enable lower costs as requirements will be validated using less expensive methods than code.
4. More Emphasis on Business Change – The BABOK Version 3 will be released sometime in 2014. There are big changes coming to the role of business analysis. The focus will be much more on understanding stakeholders and their needs, analyzing business change, and delivering value. The role of business analysis in enabling business change will become more important than defining user stories, which is primarily done by agile product owners and teams.
5. Managing Value not Tasks – According to the Gartner Group, program and portfolio management (PPM) is a growing area of need for many organizations; however, the results it delivers often don’t live up to expectations. According to Gartner, Since 2008, there has been a high rate of Project Management Office (PMO) startup activity with an implementation failure rate of more than 50%. Organizations must consider moving beyond traditional IT portfolio management to align with mission critical business objectives. The focus of PPM must shift to be able to adapt to changing strategies to create maximum business value for minimum cost, quickly. Gartner is bold to say: “PPM leaders must prepare for extreme transformation or prepare resumés. Enterprise Portfolio Management Offices (EPMOs) are beginning to emerge. The key driver is the need to merge technology and business projects under the same organization.
6. Measuring Business Outcomes – CEOs are placing more demands on CIOs to show more value from dollars invested in IT. PMOs will be asked to demonstrate how projects have improved business outcomes and achieved expected ROI. Defining Business KPIs will become a standard skill for business analysts and will become a standard part of defining business requirements. Business analysts will work with other BAs skilled in BI and analytics to report results using the KPIs defined in the project.
7. Business Analysis and Design Merge – Business analysis and design will merge and become one. This change is being reflected in name changes to BABOK knowledge areas from Version 2 to Version 3.
8. More Emphasis on User Adoption – User adoption is essential to delivering value on projects. If users do not adopt the solution, then the solution delivers no value. BAs will need to develop user centered design (UCD) and organizational change management skills to be more effective in this area. This area will become a key part of agile discovery practices.
9. PMs Place More Emphasis on Solution Scope and Requirements – Project managers have begun to realize that requirements and managing solution scope are two of the major reasons for failed and challenged projects. The Project Management Institute (PMI) has definitely shown more interest in this area by creating a Requirements Community of Practice, which encourages project managers to become involved in requirement activities. It will not be surprising if Requirements Management becomes the 11th knowledge area in the PMBOK or if PMI offers a Requirements Management Certification, directly competing with the International Institute of Business Analysis (IIBA) and its Certified Business Analysis Professional (CBAP) certification.
10. BAs Help in Choosing Cloud Solutions – More and more infrastructure and applications will be migrated to the Cloud. Business analysis will play a major role in helping the business define requirements and chose the best option for moving in this direction. Security concerns will be minimized as commercial Cloud vendors have far outpaced corporations in the security area.
[cta id=”7436″]
Customer Needs: Come Out, Come Out, Wherever You Are….
I was recently reading an article about a company featured in Fast Company magazine, who has become very successful with a very simple business model: give customers only what they want.
You might be thinking: “well, that’s what every company does.”
But, the 2013 Chaos Manifesto published by The Standish Group presents a very different story. They report that only 20% of any given product’s features are used often, 50% are hardly ever used, and the remaining 30% are used infrequently. Yikes. That literally means that about 70% of the functionality most companies are spending their money to discover and deliver to the market are not really even being used—and by extension, one can assume, needed.
As a consumer I know I can relate to that—I’m pretty sure my phone does much more than I ever use, know how to use, or care to use. You can probably relate.
But this company I was reading about in Fast Company, they didn’t really seem to have that issue because either a) they did not build anything not explicitly asked for by the market, or b) they quickly tossed any products that were not being used and moved onto research what else to develop.
Now maybe that in and of itself is not that interesting, but what I did find interesting was they approach they used to do it. And how easily they seemed to have done it—as well as how cheaply.
Some organizations spend thousands of dollars a year on market-sensing activities trying to figure out what the right product and features are to build—focus groups, surveys, market research service companies, customer visits, interviews, and the list goes on. Other companies just start firing off every requested feature to development in a constant battle against the fire of the market. And still other companies don’t even approach the market and make the decisions for them what they want. Sometimes these methods work, but many times, as evidenced by the Standish report, they do not. And all of them can be very expensive.
The key to this company’s success I was reading about? Nothing fancy really – they simply read through product reviews on Amazon, and then filled in the identified gaps with products that meet what the market is looking for. And that’s it —they have a team dedicated to browsing the comments and looking for comments such as ‘This product was okay but I wish it had…”, or “This is almost what I need, but I also need it to do…”. Then they just fill the gap by producing that product—they have literally become a million dollar company just by doing this one simple market sensing activity.
Which I find interesting for a few reasons: 1) because it seems so logical, 2) because it seems while it can take time and effort to do, it would be a relatively straightforward and accurate means of market sensing, and 3) because it removes the direct interaction between company and consumer and simply uses the market’s naturally occurring conversations to derive what they want. The company was no longer leading the conversation via a focus group, or an interview, or a survey—but they were going where the conversations around what the market wants occur in a very natural way.
And that last point is what I find most interesting.
It also reminded me of a webinar I attended a couple years ago by Keith Goffin (author of “Identifying Customers Hidden Needs”) that talked about this very concept—that even when we ask the market what the need is, we cannot really get accurate answers. And that what the market really wants, is often hiding beneath the surface, in their subconscious.
To see what I mean, I am going to run through a method covered in the webinar called the ‘repertory grid’ technique.
So, pretend you are my target market and I am looking for ways to improve the phone you currently have—I ask you to name any six features of that phone, and then put them into numbered cards as such:
And then maybe I ask you the question:
“How does feature #5 (voice command) differ from features #2 and #1?”
And you may reply something such as: “It’s easier to access than the others,” or, “It’s more fun to use than the others.” Or if you really hate one of the features you may reply something like “at least it works.”
And then I would continue on to ask you a series of similar questions all comparing and contrasting the features. And from your responses I would come up with a list of constructs to compare the other features against.
So for example, constructs from the above examples might be:
- “Easy to access”
- “Fun to use”
- “Makes me more productive”
The constructs are all the natural ways that you have come up with describing these features.
I would then take those constructs and ask you to rate them for each feature in a grid, which may look something like this:
And ask you to rate each one on a scale of 1 to 5 – so for example: “On a scale of 1 to 5, with 1 being really easy to access and 5 being incredibly frustrating, how would you rate the Email feature? How would you rate the Maps feature?” and so on.
In the end, you may have a grid similar to this:
Then, as the product manager or person responsible for discovering how a product can be improved, you can start to pull out all the highly rated scores against the features and look for improvements.
In the above case, there are quite a few 4’s and 5’s, meaning there is probably a lot of room for improvement.
So what is the biggest difference between finding out what a customer needs this way versus just asking them what features they want in a phone or how it can be improved? Well, the biggest difference is the entire conversation is driven for the most part, by the customers themselves, using their own words and without any leading. Many times when we do direct interviews, or focus groups, we are asking specific questions in a specific way—and it can limit how a customer expresses what they need in a product. When we give customers the ability to naturally express their thoughts on a product, what we get as a result is much more valuable input as to what they are looking for, and they often come up with constructs or descriptions that we as a company never would have thought to use were we coming up with questions for an interview or focus group.
There is value in letting the customer drive the conversation—whether it be through the repertory grid approach outlined above, or by going to a place where the conversation naturally occurs itself, such as Amazon product reviews. More times than not, this approach can give companies a much better shot at really developing features the market wants, features they need, and ultimately features they will use.
[cta id=”7452″]
Rescuing a Troubled Project
According to the Standish Group, over 60% of projects fail or are challenged.
Gartner Group 2011 research shows the same story; only it paints a slightly worse picture.
Based on these statistics, program/portfolio managers and PMOs need to have skills for rescuing troubled projects.
Determining if You Have a Troubled Project
It is important to determine if you have a troubled project before any significant intervention is taken. It is best to do this using predefined criterion that are administered at the PMO or portfolio level. The following criteria provide some examples:
Project Planning
- The project does not have an agreed upon vision and clear set of objectives.
- Impacts that the project will have on the business architecture have not been identified and defined.
- A thorough stakeholder analysis has not been performed.
Discovery
- The solution scope has not been clearly defined as a set of features that can be delivered independently.
- Customers and users are not adequately engaged in project discovery activities.
Delivery
- Delivery team satisfaction is low.
- Agile team commitments have not been met.
- Velocity is decreasing.
Project Performance
- The project is trending 20% or more over its estimated budget.
- The project is trending 20% or more over its estimated deadline.
Benefits Realization
- The client is extremely dissatisfied with the performance of the project team.
- Benefits as defined in the business case are not being achieved.
Project Recovery Process
Turning around a troubled project is never easy, but there are approaches that can be used that provide a good chance for success. It is important to note that success may not mean delivering the project within the original time and budget constraints. Rather the focus must now be on salvaging the project to ensure that the project addresses the business need and achieves the expected business outcomes. If it appears unlikely that the project is able to deliver the anticipated business value, then the project should be canceled instead of recovered.
The following project turnaround model presents a good method for getting the project back on track:
- Assess the Troubled Project
- Develop a Recovery Plan
- Execute the Recovery Plan
- Monitor and Measure the Recovery
Managing Solution Scope
A vast majority of projects run into trouble because solution scope is not well defined or managed. There are two types of scope on a project: project scope and solution scope. Project scope involves defining the work that will be performed. Solution scope defines the features and functions that will be included in the solution. Project managers are generally very good at defining project scope but generally not very good at defining solution scope as this is a business analysis responsibility and not part of the project management domain. However in most organizations, business analysis maturity is so low that BAs start with defining solution requirements and are not even aware of what solution scope is.
Defining solution scope is perhaps the most important part of the upfront process of planning a project. However, it is seldom done well. If you don’t know for sure what you are delivering and what the boundaries of the project are, you have virtually no chance of success. Managing solution scope is one of the most critical aspects of managing a project. However, if you have not done a good job of defining scope, managing scope will be almost impossible. Failure to define solution scope well almost always results in scope creep, as well as budget and schedule overruns.
In the most recent CHAOS Manifesto, Standish Group analysts strongly recommended two key practices concerning solution scope:
- Break the project into small independent Components or Features that can be delivered independently.
- Focus on high value features and eliminate features that provide little or no value.
The Standish Group flatly states that that “there is no need for large projects, and that any IT project can be broken into a series of small projects.” It is important not to interpret breaking down projects into smaller projects as defining milestones, phases, critical paths, and activities. Delivery of concrete and usable results demarks a successful completed project. Small projects deliver a valuable result that is actually used to create a return on investment (ROI). The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle. The probability of success is 10 to 20 times that of running a single large project.
Standish Group Research shows that 20% of features are used regularly and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. Focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. Reducing scope and not delivering 100% of the functionality is not only a valid strategy, but a prudent one.
The first step in recovering a falling project is to focus on the solution scope. If it has not been defined well, then this is the place to start in the project rescue. Organizations that place more focus on solution scope in the first place will have less need to rescue failed projects. If your organization is struggling in this area, please request a consultation from Enfocus Solutions. We offer consulting services and technology to help you in this vital area for successful projects.
[cta id=”7658″]
Requirements Management Tools versus Robust Business Analysis Tools
In one of my recent blog articles, Risk Management: Business Analysis is a Huge Risk for Most Organizations, I stated that business analysis is at a dangerously low level of maturity for most organizations as evidenced by Standish Group Research, which analyzes project performance. Standish Group Research shows that the top five reasons for failed or challenged projects are:
- Lack of user involvement
- Lack of transparency
- Poor or incomplete requirements
- Changing requirements
- Lack of business alignment
Now, examine these problems carefully; all of them are related to poor business analysis. Looking at this and other research, I firmly believe that poor business analysis is the number one cause of failed and challenged projects. According to the Business Analysis Body of Knowledge (BABOK), business analysis involves much more than just writing solution requirements. However, in many organizations, BAs only write solution requirements and do not perform other key activities specified in BABOK. For example, few business analysts are actually involved in Enterprise Analysis and Solution Assessment and Validation which are two key knowledge areas specified in the BABOK.
Many people think that Requirements Analysis and business analysis are one in the same. Requirements Analysis is only one of the six knowledge areas in BABOK. It’s important to stress that there is much more to business analysis than just writing solution requirements.
Many confuse requirements engineering and business analysis, thinking they are one in the same; however, they are not. Understanding the differences is key for successful IT projects. Requirements engineering, although helpful, is certainly not the key for success on business IT projects. Requirements engineering might address problems 3 and 4 of the Standish Group problem list, but would do little for 1, 2 and 5. Let’s explore the differences between the two.
Requirements Engineering (RE)
Requirements engineering is a systems and software engineering process which covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system. The first use of the term ‘requirements engineering’ was probably in 1979 in a TRW technical report, but the term did not come into general use until the 1990s with the publication of an IEEE Computer Society tutorial and establishment of a conference series on requirements engineering. Requirements engineering is often very rigid and engineering-focused as it originated from the IEEE world. The focus is clearly on developing engineering specifications for a product and not delivering business value in an environment that must address people, process, and technology. With the rapid adoption of agile development practices, some industry observers have questioned if requirements engineering is still relevant as it is a process for software engineering, which agile has mostly replaced.
Requirements engineering is primarily focused on building products and does not include many of the other activities involved in business analysis such as business process improvements, building a business case, or delivering business benefits. Basic traits for requirements engineering include:
- Solutions are engineering-driven and focused on delivery of product features, not business benefits.
- Requirement engineering typically deals with large complex systems in which software is only a component (e.g., airplanes, naval vessels, hydroelectric plants, etc.).
- Two primary requirements engineering activities:
- Requirements development.
- Requirements management.
- Requirements are related to products, not processes.
- Requirements engineering addresses only Functional and Non-Functional requirements while ignoring Business, Stakeholder, and Transition Requirements.
- Requirements engineering does not work well for agile development practices where lighter requirement practices are used (user stories) and focus is placed on collaboration and less on rigid engineering practices.
Business Analysis (BA)
Business analysis is much broader than requirements engineering. The focus of business analysis is to deliver solutions that improve business outcomes. Software is usually one part of the solution. Business analysis also addresses people and process issues in addition to technology. Below is a list of BA characteristics:
- Solutions are business driven and aligned with business needs.
- Business analysis is used for enterprise projects where people, process, and technology issues must be addressed.
- Four primary requirement activities:
- Elicitation.
- Requirements development.
- Requirements management.
- Requirements communication.
- Solutions are focused on using technology to help people performing business processes.
- Solutions are often purchased instead of built (ERP Systems, Cloud Applications).
- Addressing organizational change and business process change is critical for successful business analysis.
- Business analysis involves facilitating business change.
- Delivering business value and ROI are expected.
- There are five types of requirements: Business, Stakeholder, Functional, Non-Functional, and Transition.
Selecting a Business Analysis Tool
I have worked with many organizations that simply do not understand the difference between a business analysis tool and a requirements management tool. The vast majority of requirements management tools on the market support requirements engineering and provide little or no support for business analysis. A requirements management tool can work very well for defining and managing requirements for a product. However, the product that is built may not deliver any business value or may not help users perform their activities because the requirements tool used only allows for defining Functional and Non-Functional Requirements and does not allow for capturing business and stakeholder requirements. If your goal is to deliver business outcomes and help users better perform their daily activities, then chose a business analysis tool and not a requirements management tool.
At present, Enfocus Requirement Suite™ is the only true business analysis tool on the market. If you are in a Corporate IT department and you are selecting a tool for product requirements, you are probably selecting the wrong tool. IT departments deliver services and do not usually develop products. If you are looking at tools and see taglines such as the ones below, be careful to ensure that you are choosing the right tool for your needs.
- Requirements Definition and Management Software
- A Better Way to Manage Requirements and Deliver the Right Products
- Software for Managing Requirements
- A Tool for Managing Product Requirements
A business analysis tool includes many capabilities beyond just requirements. Below are distinguishing characteristics of business analysis tools:
- Addresses all knowledge areas in IIBA’s BABOK:
- Business Analysis Planning and Monitoring
- Elicitation
- Requirements Analysis
- Requirements Management and Communication
- Enterprise Analysis
- Solution Assessment and Validation
- Captures all five types of requirements as defined by the IIBA (Business, Stakeholder, Functional, Non-functional, and Transition).
- Focuses more on customer collaboration over rigid engineering specifications.
- Can define the business case within the tool.
- Addresses people, processes, and technology, not just technical specifications.
- Can trace requirements to needed business processes changes, IT services and organizational change initiatives.
- Provides a stakeholder impact assessment capability within the tool.
- Captures stakeholder needs separate from requirements with full traceability from requirements to stakeholder needs.
- Can define the problem statement within the tool.
- Can trace requirements to specific business objectives.
- Can record expected business outcomes in the form of measures or KPIs.
- Focuses on collaboration between stakeholders and developers, placing more emphasis on collaboration and less on rigid requirement documents.
- Allows stakeholders to be engaged throughout the project lifecycle, not just upfront in requirements definition.
- Allows the requirements to be used for benefits realization after the solution has been delivered.
Guidelines for Dual-Track Agile Project Management
In our previous blog on Dual-Track Agile, John Parker described the benefits of this emerging concept. Dual-track agile is an approach to agile development in which project teams are constantly working on the discovery and delivery of solutions that will deliver business value and obtain user adoption. By following the principles of dual-track agile, project managers and their teams can eliminate a lot of frustration and costs in agile development. Below are the key guidelines to implementing dual-track agile in your projects.
1. Put together a proficient discovery team with expert capabilities who are able to blend entrepreneurial skills and research gathered from the market. Your team needs to have the following skills so they can thoroughly and effectively understand the problem, recommend the best solution, and align the project with business needs:
- User Experience/User-Centered Design
- Business Analysis
- Pricing and Financial Analysis
- Customer Discovery
- Impact/Gap Analysis
- Focus on Collaboration
- Experimentation Attitude
2. Have the discovery team working one or more months ahead of the development team. The discovery team should be constantly populating the backlog with validated ideas and user stories.
3. With the help of the discovery team, create an understanding of your customers’ core problem before gathering ideas/features. Do not start putting together a solution until you have a complete understanding of the problem. Use Root Cause Analysis techniques like Fishbone Diagrams or The Five Whys to dig deep into the source of the problem and set the context for the project.
4. Develop a shared vision by hosting a vision planning workshop. Invite the product owner, business stakeholders, technical subject matter experts (SMEs), user-centered designers, and customer representatives. Before the end of the meeting, ensure everyone understands the problem or opportunity and why it is important.
5. Develop a clear set of business objectives for the project to ensure the delivered solution achieves critical business outcomes laid out in the vision. Once ideas or features are documented, business objectives will be referred to for validation. All features must align with business objectives.
6. Do not allow user stories to be defined until ideas/features are fully documented and validated.
7. With the guidance of user-centered design specialists, validate ideas/features to ensure they meet business needs and eliminate low-value features. With the help of business stakeholders, customer representatives, and technical SMEs, validate that each feature is:
- Accurate
- Complete
- Clear
- Prioritized Correctly
- Feasible
- Testable
8. For every validated feature, develop a complete set of user stories. Make sure your user stories consist of the Three C’s:
- Card
- Conversations
- Confirmations
9. Each user story needs to be written in a consistent format and follow the INVEST model:
- Independent
- Negotiable
- Valuable
- Estimable
- Sized Right or Small
- Testable
10. It’s important for the discovery team to collaborate with each other and provide support to the development team. Use collaboration mechanisms such as feedback elicitation, stand-up meetings, demonstrations, and retrospectives. Discovery teams should have frequent interaction with developers, business stakeholders, and the QA team.
If you’re a PM needing help on implementing these guidelines, Enfocus Solutions Inc. provides a complete solution for dual-track agile development by helping teams focus on discovery to ensure projects deliver value to the business, customers, and users. Download the white paper below or contact us for a consultation to find out how we provide a complete solution for powering business value, reducing waste, and increasing ROI on projects.
[cta id=”7449″]
Requirement Documents, Oh the Inefficiencies!
I’ve written a fair number of requirement documents in my business analyst lifetime, and I’m still not sure what took longer – gathering and documenting the requirements, or trying to get the business to read and approve them.
Let me know if this sounds familiar…
You spend weeks, maybe months, eliciting requirements, reviewing requirements, and documenting requirements in a nicely formatted word document with the title Business Requirements Document (or something similar) slapped on the front. You are proud of the work you have done, the diagrams you have drawn, the requirements you have logically ordered and laid out for your stakeholders to read – and you’re sure that you have made it down right simple for anybody to just open it up and review it.
You happily click send on the email, sure that your stakeholders will read it and send back their input within the requested time frame—after all, who wants to risk the project deadline, right?
Problem is, usually stakeholders don’t have the time, or the space, to review a long—and let’s be honest—often boring, requirements document. Your priority as the BA to get the requirements document reviewed and approved is unfortunately often not their priority—and it’s extremely hard to make it so. Or even when you do get their input, what you receive is often not as meaningful as you were hoping—I remember on more than one occasion receiving a requirements document back with fewer comments about the requirements themselves than about the spelling or grammar style I chose to write it in.
In today’s projects, where the dynamics of the solution is constantly shifting, the complexities increasing, and our stakeholders’ attention spans are ever so quickly decreasing (whose isn’t really?)—the inefficiencies of using a document to record, manage, review, and gain stakeholder approval for requirements needs to be questioned.
If it’s not, projects will continue to be negatively impacted by:
- Incomplete and inaccurate sets of requirements
- Delayed implementation schedules
- Lack of stakeholder engagement
- High levels of change requests during the test phase
- Lack of user adoption once the solution is implemented
- High levels of rework resulting from requirement misunderstandings
And, I’m sure you can probably name a few more that affect you as well.
We need to start acknowledging, and managing, the fact that stakeholders simply don’t have the time, or the desire, to read the stodgy documents we tend to throw at them in projects. We also need to acknowledge that much like the projects we are working on, requirements also need to be able to easily adjust and pivot with the changing dynamics of a project landscape. Business objectives can change, stakeholder needs can change, the market can change, the priorities of what we are building can change—and with those changes, the requirements need to change as well.
As business analysts, we need to be able to effectively manage them. Assessing change requests can be one of the largest challenges any project manager or business analyst faces on a project—and attempting to do it from within a large document, can make it all that much more worse. In fact, doing so poses a risk to the entire project. How can you tell what the impact of a change request will be when the traceability and context of a requirement is spread confusingly throughout a document? Wouldn’t it be easier to just see all those impacts in one place? And really that is just one small example of how managing requirements within a document can be so inefficient.
So what’s the answer?
Well, at Enfocus Solutions, we think: enough with managing the documents, time to start focusing on managing the data instead.
To effectively manage requirements means that as business analysts, we need to stop spending our time on managing the document the requirements are in, and instead focus on managing the requirements themselves.
We need a better way to:
- Review requirements with stakeholders and receive meaningful feedback to ensure the accuracy and completeness of their requirements as we move through the project.
- Establish a visible and accessible location to document the requirements for a project.
- Control the changes made to the requirements once initial approval has been achieved, and control the resulting versions of requirements that result.
- Effectively communicate changes to requirements to the right stakeholders throughout the lifetime of a project.
- Capture the context and traceability of the requirements we define—where they came from, why they are being developed, and what value they will ultimately deliver.
So what does managing data instead of documents look like?
Instead of documents, and the multiple versions that usually result…
Use a requirements management tool to establish your single source of documenting, reviewing, validating, and managing requirements throughout the lifetime of your project.
Instead of gathering stakeholder feedback in isolation of one another…
Establish transparency and generate conversation with and amongst your stakeholders using a tool that allows you to capture stakeholder comments and needs in one location on the requirements themselves, keeping the conversation visible and accessible to everyone else on the project.
Instead of validating and approving requirements all at once, after you’ve completed the document…
Validate and gain stakeholder approval as you go—eliminating the need for stakeholders to navigate their own way through a large requirements document, and enabling them to easily navigate their way to only the requirements that impact them.
Instead of limiting the participation of your project team by making them wait for a completed and approved requirements document….
Enable collaboration with them by providing visibility and access to the validated requirements as you go through the project. If you start to review with your stakeholders as you go, then developers and testers can start to work in parallel with you too. Keeping your team actively involved in the conversation from the start, is just as important as keeping your business stakeholders involved.
Instead of wanting to pull your hair out trying to manage changes to requirements after review and approval…
Manage the change requests through a defined process built into your requirements management tool, so you can easily assess the impact each change will make and control the changes that are included in each release.
And the list can really go on.
Documenting requirements is an important part of any successful project, but at the end of the day if we are spending our time and energy on managing the vehicle we are communicating them instead of the requirements themselves, there is a large risk that requirements will be overlooked, be incomplete, and ultimately not clearly define what it is the business needs to be successful.
Once the shift starts to move away from building and managing the documents that hold the requirements themselves, and more towards managing the data within them, then the opportunity for improved collaboration, requirements quality, requirements development, testing, and ultimately, project success is what results.