by Jenny Boronyak | May 2, 2014 | ITIL and Service Design, Uncategorized |
When we attended Knowledge14 in San Francisco earlier this week, one thing we noticed is how amazingly far organizations have gotten in adopting IT Service Management (ITSM). But while it does seem organizations have caught onto the fact that moving towards ITSM provides a lot of value, many have still not yet adopted or placed enough emphasis on the ITIL practices of Service Strategy and Service Design. This is a huge mistake, as ITIL offers valuable guidelines to service providers on the best ways to design and maintain services for the business. Image from ITIL Service Design One of those guidelines is to create a Service Design Package (SDP). It seems that many new service providers either neglect the SDP or create one that’s lacking in all the necessary elements. However, creating an SDP ensures your services are designed well, and according to the authors of ITIL Service Design “the better and more careful the design, the better the solution taken into live operation,” so creating a SDP is not a step you want to skip The Service Design Package (SDP) follows a service through its lifecycle from initial proposal to retirement. It contains all the information required to manage an IT service. The SDP specifies the requirements from the viewpoint of the client (not IT) and defines how these are actually fulfilled from a technical and organizational point of view. When created properly, SDPs bring a lot of value to the business. A SDP… Improves the quality of services Improves decision-making Makes implementation of new or changed services easier Improves alignment of services to the business Makes service...
by John Parker | Mar 19, 2014 | Business Analysis, ITIL and Service Design, Project Management, Uncategorized |
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...
by John Parker | Feb 3, 2014 | Business Analysis, Uncategorized |
By proactively identifying and eliminating or remedying poorly performing application assets, Application Portfolio Rationalization helps companies to: Reduce costs, Target efforts to the areas of highest return, and Maximize the business value of their application portfolios. Globalization and changing business requirements impose significant challenges on technology leaders who are under constant pressure to both innovate and reduce costs. These demands to do more with less have been exacerbated by business leaders hearing about prospective savings from use of the Cloud without understanding the impact of transition. Many organizations are electing to combine their initiatives for application rationalization and migration to the cloud. IT leaders are forced to accelerate the rollout of new systems and technologies to support the business without compromising the performance of existing applications. They must address key issues, such as balancing cost, complexity, and capacity, and also deliver business value by applying continuous improvement methodologies. Application portfolio rationalization helps organizations turn these challenges into benefits in terms of reduced costs and more value delivered to the business. Application portfolio rationalization is an important and continuous exercise for evaluating and controlling IT costs. Application portfolio rationalization involves focusing on the application portfolio looking for redundant applications, one-off technologies, applications with few users, and applications with a high cost/user ratio. With a complete understanding of the current environment, the next step is to consider what should be done to move from current to the ideal. Gartner Group research confirms that a focused application rationalization effort will typically result in substantial cost savings while improving support for the lines of business. These savings are too large to ignore. Additional...
by John Parker | Feb 18, 2013 | Business Analysis, Uncategorized |
A while back, Ellen Gottesdiener from EBG Consultants assembled a list of citations about ROI and requirements titled Do You Know Your ROI on Your Requirements Work. Ellen did an excellent job researching this topic and presents a comprehensive list of citations in her article. Also, Ellen and her business partner Mary Gorman have recently published a new book with the title Discover to Deliver: Agile Product Planning and Analysis. Ellen and Mary did a great job on this book and I would recommend it to all business analysts, and especially the ones involved in product management. Below is a brief extract from Ellen’s article. Success with Requirements Pays Off Quickly by allowing you to: Shorten your product development cycle Deliver the right product on time Boost your team’s productivity Reduce rework and conflicts arising from unclear requirements Cost Savings: Getting requirements right, early in your project, can save up to one-third or more of your overall project budget (Hooks and Farry, 2001) By investing only 10% more effort in requirements before freezing them, large, complex projects experienced significantly lower cost overruns – 30% to 130% overruns fell to 10% to 20% overruns (NASA Comptroller’s Office, reported in Hooks and Farry, 2001). The costs of requirements errors are extremely high. For example, the cost to correct errors injected early (during requirements development) multiplies as your project proceeds – costing you 50, 100, or even 400 times more as the project proceeds (Reifer, 2007; Dabney and Barber, 2003; Boehm and Basili, 2001; Nelson et al., 999; McConnell, 1996; Boehm and Papaccio, 1988). You save money by getting requirements right the...
by John Parker | Nov 16, 2012 | Business Analysis, Uncategorized |
The vast majority of IT projects seldom deliver the anticipated returns specified in the business case. Look at the same of the quotes from the sources below. “78% of Information Systems projects failed to realize even 50% of the originally identified benefits.” Source: Management Today “Only 40% of CFOs find that their IT investments are producing the returns they expected.” Source: Gartner, How to Optimize IT Investment Decisions “30-40% of systems to support business change deliver no benefit whatsoever.” Source: OGC, Successful Delivery Toolkit The reasons why benefits are seldom achieved are many. Below is a list of some of the common reasons. The business problem was poorly defined giving rise to a flawed business case. The business case was poorly developed and established an incorrect or unrealistic expectation. Requirements for the solution were inaccurate, incomplete or were poorly defined. Delivery of the solution was poorly executed. The technical solution was fundamentally flawed. The delivered solution was not effectively adopted by the business. The business changed significantly between inception and project completion. Let’s look at what can be done to achieve more benefits. Prepare a realistic and accurate business case. The business case should not just be used to secure funding, but should also be used a management tool to measure success. Section 1 – Problem Statement Section 2 – Vision Section 3 – Alternatives Section 4 – Recommended Strategy Section 5 – Benefits Section 6 – Assumptions Section 7 – Financial Analysis Section 8 – Risk and Mitigation Strategies Change the key measure for determining project success to whether the business benefits as proposed in the initial business case were achieved....
