Skip to main content

ITIL for BAs. Part II

Written by Terry Longo on . Posted in Articles. 1 Comment on ITIL for BAs. Part II

Service Strategy

If one purpose of any strategy is to express a consolidated, comprehensive view of mission and direction, then the BA should expect that an IT organization’s IT Service Strategy is embodied within the IT organization’s structure and the roles defined.

In ITIL V3 that embodiment of IT Strategy is realized through the role of the product manager, whose responsibilities include: 

  • driving service strategy 
  • managing services across their entire life cycle (concept, design, transition, operation, retirement) 
  • ownership and maintenance of the service catalog, an essential document that describes IT’s service capabilities in the customers’ terms
  • understanding IT’s service models and how to drive changes and improvements effectively through those models
  • knowing the costs and risks associated with the lines of Service they represent
  • evaluating new technologies and operating models that can be leveraged for greater efficiency and effectiveness
  • providing financial analysis of existing, planned, and proposed services
  • supporting the business in building business cases for new services or improvements to existing services

The above responsibilities are only half of the story, as they are primarily inward-focused.  On whose behalf is the product manager carrying out those activities?  In ITIL V3 it is the primary relationship the product manager has with the business s through the Business Relationship Manager (BRM), who represents the customers and their IT service requirements.  Together the product manager and the BRM work to 

  • understand the financial elements of IT Service delivery
  • express the demand the customers will have on IT Services (new and existing)
  • build business cases from a life cycle point of view
  • manage the resulting service(s) within the context of their respective IT service and business solution portfolios

In BA terms, the BRM is the business analyst.

It is interesting to note that the definition of the product manager directly addresses (I think) the question of whether a business analyst should be part of the business or part of IT – the answer is both, for the ITIL V3 product manager is, in essence, a “business analyst”, with a specific focus on IT Services.

For more information, ITIL Service Strategy Appendix B section B2 presents a concise summary of the nature and value of those two roles.  ITIL V3 books are available from most major booksellers and also from the IT Service Management Forum (itSMF) at the publications section of their Web site at http://www.itsmfusa.org/.

How to Complete a Software Development Project on Time, on Budget

Written by Cynthia Low on . Posted in Articles.

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework, and as a result, over 80 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality.

It’s a software development business analyst’s nightmare – that doesn’t seem to end.

The potential for error is further heightened because, unlike mechanical or civil engineering where the results of your efforts are tangible, the product of software development is largely conceptual.  When a manager is directing a complex project with several teams, the potential for mistakes or misdirection is especially magnified. Unlike a bridge being built from two sides of a river, significant discrepancies can creep in without an obvious reality check.

To avoid costly errors and delays, business analysts should consider seven key steps in tackling software development projects.

  1. To manage software projects effectively, business analysts need to have an explicit definition of the project’s scope. A clear demarcation of what is in and what is out, what is essential and what is would be nice to have, and what needs to be delivered at the end of the process. All major stakeholders and team members need to have a common understanding of the project goal. Ambiguities at this step can lead to major problems later that can only be resolved by a significant waste of time and money through rework.
  2. Develop concepts into clear requirements. Once stakeholders agree on a common goal, they need to refine their understanding into precise requirements, understandable to all. While it is common for requirements to evolve, starting from a specific requirements baseline provides a foundation to ensure the development process doesn’t drift. By ensuring that stakeholders are deeply involved in defining requirements, business analysts have a solid, universal understanding of the project’s path and scope.
  3. If the project is complex, use models that can be updated as the project evolves. Models represent the product in varying levels of detail and from various perspectives.  Sometimes, there is resistance to building models due to the effort required to maintain them, as new and different elements are incorporated. It is precisely because software development is so complicated that models are needed. With so many conceptual layers being tied together, it can be difficult to keep track of each and every element and their interrelationships. You wouldn’t consider building a bridge without a model. Why would you consider developing software, which is every bit as complicated, without one?
  4. Manage expectations through the project. As software development proceeds, stakeholders often suggest that more functionality be added to the project beyond its original intent. It’s necessary to rely on more than the legal contract to keep projects focused. As more people become involved in the project, regular get-togethers become even more important to ensure that all stakeholders stay aligned.  
  5. Keep the model up to date. Feedback loops are an essential part of most successful projects, and software development is no different. While it might seem time-consuming, keeping the model current provides a touchstone for all stakeholders as the project progresses. It helps maintain focus and exposes when any aspect of the development drifts from its original, or modified, intent. As much as possible, design the model so that it can be updated automatically.
  6. Decompose the model. The model should be designed in such a way that its constituent parts align with work tasks of the team.  In this way, the model parts can be delegated to individual teams to develop or maintain, and later reassembled as needed, to ensure overall integrity at regular milestones.  The process should be managed so that teams, including subcontractors, can come back to the model every so often for a reality check. By so doing, the business analyst keeps the potential for significant rework or outright failure at a minimum.
  7. The process should be built so that all aspects of the model, including those that have progressed, are pulled together regularly to ensure that everything still fits and that modules under development are still proceeding toward the ultimate goal.

But Won’t it Cost More?

Using a management structure that relies on a series of reality checks requires a project budget that allocates time and money for periodic review. The result, however, is that this marginal investment yields far more payback in terms of reduced rework.   An accurate and representative model is a catalyst for more valuable and more frequent feedback. Feedback loops are designed precisely to reduce risk and are found in nearly all engineering disciplines.

With software development projects spending on average 40 percent of their effort on rework, it is worthwhile to use an effective model to ensure your project achieves success.

Consider the alternative: A project that the client rejects, one that has to be reworked hastily, held together by shunts and duct tape. Not only are project funds wasted unnecessarily, but the delivered product’s quality suffers.   Status quo is the expensive path.

Tony Higgins is Vice-President of products at Blueprint Systems. He can be reached at [email protected].

ITIL for BAs. Part I

Written by Terry Longo on . Posted in Articles. 2 Comments on ITIL for BAs. Part I

If you are a regular reader of this blog, you know of my deep interest in both ITIL and BA, and particularly their interdependencies.  One driver behind that interest is my observation (validated by numerous colleagues) that, all too often, people in specific practices (PM, software development, IT operations, BPE, SOA, BA, etc.) are strong and focused in their domain but neglect the touchpoints and integrations with other practices.  It is a sort of “best practice” silo phenomenon analogous to the technology silos in IT organizations.

There is a significant amount of overlap between the BABOK and ITIL, with lots to sort out.  Furthermore, the differences between the two practices in terms of activities, inputs, outputs, roles, metrics, and organizational structure are noteworthy, and because of ITIL’s significant dependence on strong BA, those differences will need to be reconciled to get the most out of our BA/ITIL integration efforts.

In this post I would like to kick off a deeper treatment of the BA/ITIL connections, starting with a description of ITIL v3’s overall structure in terms of the service life cycle and key processes.  Future posts will then cover specific touchpoints between BA and IT.

So, let’s begin at the beginning.  ITIL is all about encapsulating IT (the infrastructure and the organization) such that the users and customers view IT as a service provider that is integrated into the business.  ITIL’s definition of a service is:

a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks

In other words, by adopting ITIL, an IT organization is saying to its customers, “tell us what you need, in your terms, and we’ll take care of the nuts and bolts”.  This means that the business sets the context that defines the value of IT’s contribution, which is, delivering solutions that satisfy requirements that facilitate desired business outcomes.

When you add up (a) the complexities of IT-based solutions, (b) the increased rate of change in business and IT, and (c) management’s need for monitoring and control, it is clear that a BA needs to be tightly involved with IT throughout the life cycle of an IT-based solution.

ITIL v3 is especially well-suited to accommodate such involvement.  In its simplest terms, the core of ITIL v3 is a set of five books reflecting the IT Service life cycle phases of

  • Service Strategy
  • Service Design
  • Service Transition
  • Service Operation
  • Continual Service Improvement

At this level it is easy to see that the service life cycle is a very effective context for the BA’s activities.  Let’s look one level deeper now, into the specific processes associated with each of those life cycles – the process names alone are sufficient to suggest the breadth of opportunities BAs have to drive BA/ITIL integration:

  • Service Strategy
    • Strategy Generation
    • Service Portfolio Management
    • Demand Management
    • Financial Management
  • Service Design 
    • Service Catalog Management
    • Information Security Management
    • Supplier Management 
    • IT Service Continuity Management
    • Service Level Management
    • Capacity Management
    • Availability Management
  • Service Transition
    • Transition Planning and Support
    • Change Management
    • Service Asset and Configuration Management
    • Release and Deployment Management
    • Service Validation and Testing
    • Evaluation
    • Knowledge Management
  • Service Operation
    • Event Management
    • Incident Management
    • Request Fulfillment 
    • Access Management
    • Problem Management
  • Continual Service Improvement

For the BA, several of the above processes, such as Service Validation and Testing, Change Management, and Financial Management, jump off the page because of their relevance to BA.

Beginning with our next post, we’ll start to tackle the above processes individually in terms of their overall purpose and their relevance to BA as defined in the BABOK.

Meanwhile, I encourage you to post your comments/thoughts!

Stories from the Front!

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on Stories from the Front!

We have received REAL news from CBAPs at the front!  Check these samples out, and send me an email ([email protected]) letting me know which one(s) you relate to the most, and sharing YOUR story.

Story 1

I wrote and passed my CBAP in April of this year.  In February I was assigned to a new project and since I was deep into study mode, I was able to apply some new stuff I had learned to the project I was on.  I continue to refer to the BABOK regularly, refreshing my existing skills and utilizing new knowledge wherever I can.

In July, my manager interviewed a number of people for my mid-year performance review.  The Business Service Owner of my project told her that until now he had never really understood what it was that a BA did, and that I had raised the bar for the other BAs in the company.

Wow!

Story 2

Up to the moment I was certified I was convinced that I was pursuing a worthy goal.

Most people in the profession have been quite supportive but . . . those outside it seem bored or threatened by it.

After receiving my certification, there has been some resentment felt by me from other analysts and from IT architects.

There has been a certain amount of derision and mockery – one fellow began teasing me about my use of the CBAP designation (in my e-mail signature for example) as if I was trying to assume airs.

I think we have a LONG WAY to go to achieve any appreciation for what the designation means.

Story 3

Here are a few observations and experiences since certifying:

A better perspective on the big picture, maybe this is just my “proudness” of being a CBAP!

I have a better approach to BA work; from the high-level business  requirements to functional.

I have read more articles about PM/BA and about BA with Agile (we currently use Scrum).

In my travels, I still see the need to educate people on what a BA can do for a project!

I have gained more appreciation to work towards Enterprise Analysis and how BA can really make an impact with this.

NEXT MONTH

YOUR story here – or I will be forced to tell mine!

Thanks to my gentle readers for their frankness and willingness to share.  More shall be revealed.

Have fun!

Designing Great Leadership Development Workshops

Written by Cynthia Low on . Posted in Articles.

Ten Core Design Principles

Leadership development workshops are very expensive. And I’m not just referring to the cost of facilities, materials, trainers, and bagels. When a company takes 20 or so managers out of the organization for several days, it is making a significant investment in their development. Those of us who are the architects of these workshops need to ask ourselves the question: Have we designed a workshop that is worthy of this investment? We at Bluepoint have been delivering leadership workshops for over twenty years and have learned that there are 10 core design principles that lead to a great learning experience. I would like to share these with you.

1) Research-based Content

A colleague of ours once mused that many leadership workshops appear to have been created by two guys in a bar in Milwaukee and recorded on the back of a beer coaster. The truth is that anyone can cobble together some interesting exercises and experiences, but to what end? We know the outcomes of great organization leadership…alignment, engagement, retention, productivity, teamwork, agility, to name a few. There is little mystery here. What many designers ignore is all the research that tells us what specific leadership behaviors, practices and approaches will create these outcomes. A good leadership workshop is grounded in this research and, as such, will equip participants with the capability to make an immediate, positive impact on their organizations.

2) Engagement

The frenzied pace that most managers face today has turned the otherwise calm and thoughtful participant into a skittish, distracted bystander, infected by a self-imposed form of ADD with one eye on his or her Blackberry and the other eye on the door. It’s not that these managers are disinterested in their professional development; they are simply products of today’s frenetic organizations. To get their attention, they must be entertained. While describing a good leadership workshop as entertaining may sound like a call to design a boondoggle, unless the workshop can successfully compete with the myriad of distractions facing today’s manager, we will simply be hosting adult day-care. The famous communications guru, Marshall McLuhan, made the connection even more direct with this statement: “It’s misleading to suppose there’s any basic difference between education and entertainment.” Videos, stories, games, debates, physical experiences and colorful materials all play an important role in participant engagement.

3) Story-telling

Every participant comes to the workshop with their own unique leadership story that has grown out of their experiences, beliefs, fears, biases and aspirations. A great workshop challenges the participant to create a bigger story for him or herself and the people that they lead. This can only happen when the participant has the opportunity to tell his or her current story and have it honored in the classroom. Once this happens, a new story can be crafted. The greater the story, the greater the development.

4) Feedback

No workshop ingredient is more potent than feedback. Whether it be multi-rater assessments or direct one-on-one communication, feedback is a powerful stimulus for personal change. And that’s what leadership development really is…personal change. What limits the use of feedback in leadership workshops? I believe it is largely our own arrogance. Too often we feel that the participant cannot handle the feedback. They are too fragile. They will somehow be irreparably damaged by our words or those of fellow participants. Or it may be our own insecurities. We will lose control of the workshop. Emotions will run rampant. We will not be able to handle the resulting carnage. Remember, the workshop is not about you; it’s about the participant. Be bold in creating a feedback-rich environment. The participants will thank you for the gift, maybe not now, but someday.

5) Appreciation

The problem with many leadership development workshops is that there is an underlying assumption that the ideal leader needs to develop a predetermined set of corporate competencies while becoming some fantastic amalgamation of Mother Teresa, Martin Luther King, Gandhi and Jack Welch. Let’s leave that idea to the boys at the bar in Milwaukee. We do not discard these elements entirely from the design process. Corporate culture and strategy rightly have a bearing on workshop design, and there is also much we can learn from the great leaders of the past. However, the best workshops are based on the assumption that all participants come uniquely gifted for the challenge of leadership, and the role of the workshop is to help them identify and cultivate these gifts. It is not our job to help them become the next Steve Jobs, but rather someone much more potent…the best leadership version of themselves. A workshop that is designed to help the participants accelerate the development of their natural strengths is much more potent than one designed to fix the participant or change him or her into the model corporate leader.

6) Intense Experiences

I have asked thousands of workshop participants to reflect on the following five items and select the one that had the most influence on their development as a leader.

(i) Reading and Research
(ii) Performance Appraisals
(iii) Coaching and Mentoring
(iv) Challenging Experiences
(v) Formal Training

Challenging Experiences” was selected by over 90 % of the respondents. (It’s interesting to note that Performance Appraisals always comes in dead last, but that’s a topic for another day.) Even though most designers are keenly aware of these findings, there is a great temptation to fill the workshop agenda with content that is largely extraneous such as succession planning models, managerial competencies, and corporate values. While the intention to provide material that can be applied back on the job is laudable, this information is largely ignored. People can read. Give them the content beforehand. Use the workshop as a learning laboratory where the participants are confronted with real leadership situations. Challenge them to lead at higher levels. Create a curriculum that exposes participants to intense experiences, and allow them to experiment with new behaviors and approaches. This will accelerate their learning and development. (By the way, most savvy managers have read all the corporate tenets and many of the important books on leadership anyway.)

7) Peer Coaching

In my ongoing survey, Coaching and Mentoring always comes in second. One-on-one learning processes are very powerful because, for a period of time, it really is all about me. Because coaching requires no content knowledge, any participant can coach another with a little guidance. For those of us who make our living standing in the front of a classroom trying to be insightful, witty and sage-like, it is difficult to accept the fact that the average peer coaching session is much more effective than our most brilliant lecture. Whenever possible, get your body and ego out of the way and let the participants talk to each other.

8) Self-awareness

It has been said that leadership development is an inside-out game. I like the way Manfred Kets De Vries puts it: “Healthy leaders are passionate…They are very talented in self-observation and self-analysis; the best leaders are highly motivated to spend time in self-reflection.” (Harvard Business Review, January, 2003) The leadership development workshop provides the perfect opportunity for the leader to step out of his or her chaotic schedule, put it in neutral, and take a long, fresh look inward. After all, the only thing participants can work on to improve their leadership is themselves. Put sufficient white space into the workshop design so the participant can personalize the learning. Most managers cannot remember the last time they took 15 minutes in complete silence to contemplate their own leadership journey. Give them the 15 minutes.

9) Performance Breakthroughs

The most frequently voiced dissatisfaction with leadership workshops is the lack of application on the job. It’s not because workshop participants do not want to change; it’s just that real change is so difficult. The pressures of the job, lack of support from their manager, no time…the list goes on. Significant improvement in leadership effectiveness rarely occurs in one big leap. We don’t see the freshly-trained leader walking through the hallways wearing saffron-colored robes, musing about shared community values and throwing rose petals on others (metaphorically speaking, that is). Change occurs incrementally and is fueled by short-term successes – a process that needs to start in the classroom. Bar the classroom door and let no one leave until they have demonstrated at least ten performance breakthroughs (again, metaphorically speaking…I think). Real change starts in the workshop, not back in the office. Start the habit of experimentation and incremental change in the workshop.

10) Learning Accountability

I kick-off many of my leadership coaching assignments with the eternally irritating question: “So, Sally, if nothing changes in your performance what is likely to happen?” Besides the mischievous delight I take in tormenting my clients, I have learned that I can serve them best by insisting that they take full responsibility for their actions, decisions, learning and future. Unless they take personal accountability for their development, there will always be someone else to blame…their board, their staff, their customer, their mother. So too with a leadership workshop. The question that needs to be oft asked at the workshop is “So, George, what have you learned about yourself and what are you going to do about it?

Our clients often report that the two or three days spent in our leadership development workshops were some of the most important days of their careers. Is this because we have great facilitators? Most certainly. A great facilitator can turn almost any curriculum into an important learning experience. But it is also because we try to adhere to the above design principles which, in essence, tell us that the workshop is not about us…it’s about the participant.

Gregg Thompson is a principle of Bluepoint Leadership Development (Canada) and the author of Unleashed! Expecting Greatness and Other Secrets of Coaching for Exceptional Performance. He can be reached at [email protected] or 604-313-5357.