Tag: Learning

Things We Can Learn from the Italian Stallion. Part 2.

Written by Kupe Kupersmith on May 11, 2010. Posted in Articles. 1 Comment on Things We Can Learn from the Italian Stallion. Part 2.

This is my blog post sequel covering the lessons we can learn from Rocky III and Rocky IV. For the first part see Things We Can Learn from the Italian Stallion.

Rocky III

At the end of Rocky II, Rocky wins the title of heavyweight champion. He is now very wealthy and defends his title 10 times. In the beginning of Rocky III a real contender wants a piece of Rocky Balboa. His name…Clubber Lang.

Stay Hungry

Rocky has been living the good life for some years now beating up on has-beens and raking in the cash. When Clubber Lang comes along Rocky is not ready. While Clubber was training to win, Rocky had his training sessions at a hotel taking pictures with fans, selling merchandise and so on. He was doing everything, but training. Rocky was not hungry. He was the champ, what can stop him? Well, Clubber Lang stopped him. Rocky was not prepared and lost badly.

As a BA you always need to be prepared. Every initiative you work on is different. Just because you may have broad experience and a history of success you need to stay hungry.

Think of your next project as Clubber Lang. Always remember to be prepared and have the eye of the tiger! Your preparation is the act of developing a business analysis work plan. By having a plan for your work you will have a roadmap of where you are going and have thought through many of the issues that may pop-up during a project. Think about the characteristics of the people you’ll be working with. Some examples include each stakeholder’s preferred communication style, physical location, availability, and level of formality expected of your deliverables. Think about the characteristics of the project. Some examples include the type of project (COTS, new development, enhancements), the project priority, and how many interfaces are impacted by the project. Think about the processes you need to follow. Some things to consider are what methodologies are being used within your organization and what templates are used for deliverables.

Don’t be Afraid of Change

After Rocky’s loss to Clubber Lang, the great manager, Mickey Goldmill, died of a heart attack. In a bizarre turn of events Rocky went to train with his old rival Apollo Creed to take another stab at Clubber. In the first bout Apollo noticed how slow Rocky was and that he needed some quickness to avoid the thundering blows from Clubber. Apollo had Rocky focus on techniques that helped him move his feet. Initially Rocky was clumsy and struggling through these techniques. He was obviously frustrated. To try and motivate Rocky, Apollo tells him “it takes a real man to change.” That was one piece that helped Rocky excel to another level and eventually defeat Clubber Lang.

My new saying is “It takes a real BA to change”. I have said before we have to continuously learn and adapt to tackle the next project or situation. Yes, it will be frustrating at times, but the rewards are huge. Don’t be afraid to make mistakes. Those are the best learning opportunities. Use your community to share ideas and learn from others’ experiences. In Rocky III, Rocky trained with his old rival. Not that we have rival BAs, but don’t just talk with people that approach things like you do. Find people at your local IIBA chapter, online communities, or in your company that have a different style or take an alternative approach to situations.

Rocky IV

Rocky’s dethroning of Apollo Creed in Rocky II did not sit well with Apollo’s ego. He misses the limelight, and the cheers of the crowd. When the opportunity to get back into the public’s eye arose with a bout originally meant as an exhibition fight pitting Rocky against Russian super boxer, Ivan Drago, Apollo jumped at the chance to fight again. So Apollo signs up for a fight with Drago with Rocky in his corner.

Throw in the Towel

In the first round of the fight between Apollo and Drago, Drago pummels Apollo. At the end of the round Rocky says he needs to stop the fight. He pleads with Apollo to stop the fight, but Apollo tells Rocky “Don’t stop the fight…no matter what!” In round two Drago continued the pounding. Apollo’s wife and trainer were screaming to stop the fight. Rocky picked up the towel, but never threw it in the ring to stop the fight. With one more punch Drago killed Apollo.

As business analysts many of you may not work on life and death projects, but you have to know when to throw in the towel. In an earlier post, Get Your Head Out of the Weeds, I wrote about needing to get out of the detail and take a look at the bigger picture to make sure your efforts are still heading towards the goal of the project and company goals. If you see the project is off track, throw in the towel, because If the project is off track the direction of the project needs to be realigned or even stopped.

I recently spoke to a group of BAs about recommending a re-alignment or stopping the project. A response from the crowd indicated that doing that is a career ending move at his company. The reason being there are people at high levels that have personal reasons for seeing a project though even if it does not meet company goals.

My response to that comment is this is not an easy decision. But, if you don’t throw in the towel the company may not be alive for long. If enough bad decisions are made you may not have a job there anyway.

Kupe

Don’t forget to leave your comments below

Things We Can Learn from the Italian Stallion. Part 1.

Written by Kupe Kupersmith on April 27, 2010. Posted in Articles.

OK, I’m coming clean. My all time favorite movies are from the Rocky saga or “hexology”; Rocky, Rocky II, Rocky III, Rocky IV, Rocky V, and Rocky Balboa (number VI). Every now and then I watch one of the movies and never get tired of the scenes of Rocky training or battling the next opponent in the ring. But, there is more to the Rocky movies than just boxing. There are lessons we can all learn from Rocky Balboa. I decided to dedicate this blog post to the greatest boxer to ever live! Let’s see what we can learn from the first two Rocky Movies.

Rocky

Mentorship

As part of our personal and career development we should all find mentors and be a mentor for someone else. There are many benefits to being a mentor including working on your listening and leadership skills. Being a mentee will allow you to learn valuable lessons from someone who has priceless experience and has already been where you are at this point in your career.

Throughout the Rocky movie, the concept of mentorship kept popping out to me. There is a scene where a young girl, Little Marie, from Rocky’s neighborhood is hanging out with some older boys on the street corner. Rocky pulls her away and walks her home. During the walk home he is trying to give her advice about life and how the people she associates with will influence who she is as she grows up. As Little Marie is walking into her house she turns and says to Rocky, “Screw you creepo”. As Rocky walks away he mumbles, “Yeah, who am I to give advice.” Don’t think you can’t be a mentor. You have experiences that can help others. Little Marie ends up thanking him later.

Later in the movie after Rocky decides to fight Apollo Creed he does not accept help from anyone to help train and prepare for the fight. Finally he comes around and gets Mickey to be his trainer and even gets Paulie, his future brother-in-law, involved. In the end he is prepared for battle. We all need mentors, we can all learn from others that have experienced things we have not. Do not be ashamed to have a mentor. You do not have to do this alone.

As BA professionals you can find mentors and mentees within your family, company, or organizations like the IIBA. Also, check out this site for mentoring tips, http://www.mentoringgroup.com/.

Rocky II

In case you are not as familiar with the Rocky movies as I am, here is a little recap of what happens at the end of Rocky. Rocky goes 15 rounds with Apollo Creed. Rocky’s right eye is badly damaged and the peripheral vision in that eye is all but gone. At the end of the fight both Rocky and Apollo say there will not be a rematch.

Now on to Rocky II where we learn some important lessons about checking our egos at the door and never saying never.

Ego

Since Apollo was supposed to finish off Rocky in three rounds in their first fight, Apollo was getting abused in the media and received a ton of hate mail, basically calling him a joke, washed up, etc. Apollo then started calling for a rematch with Rocky. Even though his trainers, managers, and family all thought it was a bad idea he kept pressing for a rematch. He wanted this rematch because of his ego not because it was the right thing to do.

As BAs we need to leave our egos at the door when working on projects. The project is not about us. Our goal is to do what is right for the project. If your mindset is focused on the project needs, the project will be a success and you will get recognition. Remember, it is not what the project can do for you, but what you can do for the project!

“There Ain’t No Can’ts”

“There ain’t no can’ts” is such a great line from the great manager Mickey Goldmill. Apollo pushed and pushed until Rocky and Mick finally agreed to the rematch. The problem was that Rocky’s eye was so bad that he could not fight as a Southpaw (left handed). Since his peripheral vision was so poor he would never see punches coming from Apollo until they were right on his face if he fought left-handed. So Mick was pushing Rocky to become a right-handed fighter. After a number of times with Rocky saying “I can’t do it Mick.” Mick yells back “there ain’t no can’ts.”

Every situation we encounter as BAs is slightly different. The project characteristics are different; the people we work with are different. We cannot use the same techniques on every project we work on. Always try to learn new techniques and skills and try them at the appropriate times on projects. If you don’t adapt the “punch” you may not see is a great opportunity. Never say “I can’t do it, Mick.”

In future posts I’ll discuss lessons learned from the last four movies of the saga. Oh darn, I guess I’ll have to watch the movies again!!

Kupe

The Business Context Model; As Good as it Gets

Written by Suzanne Jane Maxted on December 1, 2008. Posted in Articles. 2 Comments on The Business Context Model; As Good as it Gets

The Greek philosopher Socrates said “In the world of knowledge the idea of the good appears last of all, and is seen only with effort”. This article proposes that as business analysts we must have the audacity to seek out the good of a project using thought and effort to find the real business goals early on.

A business context model needs to express the current business problem and to propose the goodness and scope of a project.

I vividly recall after one particular business context modelling workshop, a senior business manager at a government agency said to me “if only we had started project x in this way, we would have reached agreement about what we were trying to do so much faster.” I have received positive feedback from stakeholders in multiple projects and also from other business analysts who see this technique as a useful tool to engage the business and to orient themselves in the program of work.

The business context model should identify the actors (people, organisations, systems) who play a significant role in the business process or in the business domain, and the business areas of interest relevant to the scope of the work and potential change which may require exploration and further analysis.

At this early point in the project we are business modelling at a very high-level in a fairly imprecise way i.e. taking a helicopter view of the business. We should not model detail such as inputs, outputs, business rules, attributes, operations, or states. We are simply trying to set the scene. By doing this graphically, we gain all the usual benefits of modelling, not least using the business context model as a vehicle for merging differing business viewpoints quickly, and for asking the right questions.

We may start more detailed analysis alongside our context modelling depending on our style of modelling. We may create a snapshot context model to kick-start our project, or we may continue to correct the context models through the project, again, depending on need or style.

I have seen all manner of “context” diagrams – current state, future state, environment diagrams, system diagrams, network diagrams, communication diagrams, business process diagrams, relationship maps, organisation charts, etc. Most of these use inconsistent notation within the diagrams themselves and, more significantly, do not set the scene for a newcomer. They are usually meaningless and business illiterate. Putting business context modelling “in context”, we need a snapshot of the business and its problem and another of its intention.

How do we start modelling context? After gathering the business customers in a room, the end customer is the first thing I draw on the whiteboard. Otherwise I am unable to ask meaningful questions about the problem or to begin the task of analysis. Then we need to discuss the problem and draw it; this represents the current state only and the reason for initiating the piece of work. The example below represents the current problem with importing and exporting goods in some countries.

For readers not familiar with the Unified Modelling Language (UML), a package indicates an area of interest. A stick man represents any actor in the business domain – a person, an organisation (which in turn represents its customer facing channel such as a website or business-to-business gateway), or a system. I prefer to show a system as a stick man because I need to remember, as a business analyst, that it is playing a part i.e. it is an actor in the business process, performing some of the business activities. I am not in the business of drawing a map of the organisation’s systems but of focusing on the business activity and business logic. It is also worth bearing in mind that when modelling context, we are not yet trying to elicit software requirements.

I use the UML notation for context modelling because the modelling language is consistent with other model artefacts, such as a business domain model (please see my article, The Importance of Business Domain Modelling in the November 1/08 Business Analyst Times). It is understood worldwide and by audiences outside the current piece of work, for example, another business analyst on another project, and I can reuse or trace to elements already created.

I have always had positive feedback from my business customers while using the UML notation. Moreover, they have always understood what we have created together in the UML. There is no perception that I am using “IT speak”. In workshops, I talk about the business objects that we are interested in and only briefly mention, as we go along, the four or five simple symbols that I will introduce that day. I can only say that, as a business modeller and analyst, it is so much better, so much easier, so much quicker and so much fun compared to all the other techniques I have tried and used over the years.

The following business context model expresses how to “make good” the import / export problem expressed above. The scope of the project is indicated by the boundary box. I have named the new package as “new bunch of stuff” to highlight that we need to think carefully about a new name. We can include important statements such as business objectives – they may be sourced from a project brief, from some statements made and clarified in the context modelling workshop, or from any other source such as a staff communication from the Chief Executive.

Critical to the business modelling activity is traceability, from our solution defined elements, such as a use case, to the original business statements, such as business outcomes, objectives, benefits or scope statements, which the project activity is addressing. By including significant project statements in our model we begin immediately to create traceability and business engagement to clarify meaning.

Spending an hour or two in workshop with our business customers at this stage will save hours of revisiting these discussions amongst individuals. The workshop might be intense and hard going but it sets us up well for a smoother run when we begin modelling proper.

Replicating the model in a good modelling tool to formalise what was agreed in the workshop takes very little time and is simply a rubber stamp exercise, while of course having the enormous benefit of being straightforward, explicit and not open to individual interpretations and agendas. As an aside, in this example the scope context model took less time to create than the problem context model because I reused the model elements already created.

We can introduce other model elements for clarity. In this new example, the following context model expressing scope includes a package that contains a particular service offering (as an object) as a scope statement. We might also add primary information flows such as “customer order”. Of course, by moving the boundary box we can easily express the scope of another project.

A package in the UML can be used as a way of breaking up the mass of business complexity into manageable chunks; I use them to indicate a business area of interest. It is for each business analyst to judge just how these are cut, however it is important to name the packages in the same way that the business customers think of them. The general guideline is to use the package to contain a “bunch of stuff”. Hence, collective nouns are good words to use e.g. xyz management, family. I have named packages as departments, areas of functionality that align with an industry pattern e.g. sales order management, or again, simply a ‘bunch of stuff’ e.g. border security.

If we put effort into seeing the good in a business or in a project we can easily set ourselves up well for further analysis and full traceability to the original business need, saving us so much time later. Each area of interest could be the basis for some business process relevant to the piece of work. The package name may become a swimlane of activity in the first cut of our business process, alongside swimlanes for each actor identified in the context model, if appropriate. The packages within our boundary box will contain the business logic, rules and use cases to support the business activities and interactions in scope. One of our goals as modellers is to give ourselves maximum opportunity to reuse model elements already created.

We can use context modelling for anything important we wish to think about, perhaps even for making family plans or for helping us to think through strategic decisions and commitments, and regulatory requirements. Below is an incomplete example that I baked earlier about reaching fulfilment in all aspects of life.

The packages, actors and associations have been depicted in this way to allow analysis to take place, the results of which may relate directly to elements in the context model. We are aiming to reduce our workload and reuse work already done. Using a good modelling tool, not a drawing tool, allows us to do this provided the notation is consistent and is used correctly, i.e. we do not deviate from the standard UML to Pidgin UML. After all, we do not use Pidgin English if clarity is the order of the day in our written material.

If we are honest with ourselves and listen to the problem statements made by our project managers (“it takes too long”), our solution architects (“the requirements are not clear or consistent with one another”) and our business customers (“I don’t have the time to review so much written work or indeed the time to wait for it.”), we would stop writing and spend only the time it takes to clarify a few significant verbal statements as a baseline for traceability purposes, and invest in the intellectual activity required to model the business. We must use our time asking all the right questions, listening carefully to the answers, capturing and structuring the knowledge gathered as clearly and as explicitly as possible, using a formal notation such as the UML.

As Jim and Michele McCarthy say in their book Dynamics of Software Development, which provides us with rules for delivering great software on time, “the real task of software development management is to marshal as much intellect as possible …” If such investment is made in the early stages of a project, the business analyst can capture the essence of a business vision, the goodness of a project and then focus on channelling the business intellectual property (IP) into the subsequent business analysis artefacts.

Modelling the business context is not a mechanical assembly line task to map some of the things that already exist in the organisation. It is an intellectual activity that requires the business analyst to elicit the business problem and to visualise with the business how to make good that problem.

In a future article, we will look at modelling the business process and the rules that govern the activities it comprises.

This article is based on one of the “Truth, Beauty & Goodness” presentation series given by the author in 2008 in Wellington, New Zealand. The author wishes to express her thanks to the following people for their thoughts and ideas freely contributed to this article: LD, BL, JM, HT.

Suzanne Jane Maxted is a Certified IT Professional Member of the British Computer Society. She gained a Bachelor of Honours degree from the University of Sussex, England, in Mathematics & Statistics with European Studies (French). Suzanne is a business analyst with 16 years experience from around the world. She is an accomplished workshop facilitator and presenter in the business analysis space and has given presentations to senior Member State representatives at the European Commission and at the United Nations, among others. She takes pride in applying logic and order to differing business viewpoints and in communicating common understanding. Suzanne teaches ballet to 3-8 year olds on Saturday mornings and fills her spare time dancing and having fun with her two little children. Suzanne can be reached at [email protected] or [email protected]

ITSM Work Sessions: Lessons Learned

Written by Richard Lannon on May 15, 2008. Posted in Articles.

Over the last few years I have facilitated several Information Technology Service Management (ITSM) work sessions within the oil and gas and utility industries. The challenge was to build consensus through identifying what is important, making recommendations and decisions, and establish direction that would enable the IT organization to improve processes and services offered to their customers. This article briefly outlines a number of lessons learned that came from our experiences.

An ITSM Work Session should provide the foundation for your organization to create the blueprint to propel IT services and business value forward. In establishing an ITSM initiative the following key groups must be involved:

Strategic: CIO and Directors to establish strategic intent, vision and enterprise objectives

Tactical: Directors and Managers to establish improvement objectives, priorities and program charter

Operational: Managers and Key Stake-holders to establish solution, roadmap, business case and project charters.

Fundamental to any ITSM session, when engaging these groups, is to develop a clear problem definition, defined and approved by the executives or senior steering committee. This is an area in which IT often falls short. The lack of a clear problem definition negatively impacts the tactical and operational levels of the organization, and limits the ability to move forward.

When working with your teams, build an understanding of all the work that is taking place in the IT department right now, and how it fits within the ITSM support and delivery relationship models. Discussion, training and clarity will be required to ensure your people understand the ITSM relationship and delivery model. By engaging people in a defined work exercise, your teams can map out and see how their work aligns with your ITSM program requirements. This is effective in establishing leadership and team buy-in.

Establish a clear understanding of your points of pain (PoPs) and the IT maturity. PoPs can be established through focused brainstorming sessions. Once collected, your PoPs should be looked at from an organizational and process maturity perspective. This is often missed, as IT has a habit of looking only at processes and tools to solve problems. Align your PoPs with the industry maturity model standards (non-existence, chaos, reactive, proactive, service, value). It is important that the content be translated into a service management maturity grid and aligned with the Information Technology Infrastructure Library (ITIL) process categories. Work to obtain various IT teams, customers and business representatives’ perspective on the ITSM organizational and process maturity levels. This builds some reality into the PoPs and maturity levels thinking by dislodging IT from a position of working in isolation.

Build a business case and program plan that can be activated by your people. At this point you are seeking clear recommendations and improvement objectives (what), benefit realization (why), tactical needs (how) and time frame (when) for which to move your organization forward with your ITSM program. This is the foundation for your ITSM program business case and charter that will be divided into project and operational requirements. You will need a solid approved business case and charter to enable you to navigate the challenges that will unfold on your journey and to clearly articulate the streams of work to be completed. There needs to be an executive team or steering committee assigned to provide clear strategic guidance. When forming and using a steering committee, their mandate must be strategic and clear. Tactical, task-based reporting can be left to the project management teams and their need for task-based results and status meetings.

Recognize that ITSM is not an IT tool solution. From a business perspective, IT needs to stop chasing tool solutions, and “flavor-of-the-month quick fixes.” Ultimately, the ITSM program is a business organizational change program that seeks to align IT with the business objectives and requirements, improve processes and change culture in an effort to control or decrease costs, increase productivity and contribute to the bottom-line. ITSM programs need to be effectively operationalized. Therefore change management and communication must be at the forefront.

Work with your teams to have them answer “WIIFM” and “WIIFT” questions (what is in it for me and what is in it for them). Ensure you established the fears, uncertainties and doubts (FUDs). Be prepared to have a long FUDs list. These will need to be acknowledged and managed within the context of the ITSM program and the change management and communications plan. Use your teams and people to establish a communication plan that takes into consideration your target audience and communication needs. Every organization has an approach to communications that may or may not align with their corporate culture. Prepare a clear communications strategy and follow it.

The information in this article is based on feedback obtained during facilitated ITSM work sessions and the work of dedicated IT professionals. Efforts focused on consideration for the strategic, tactical and operational requirements. Ultimately the goal was to improve IT. It can be done. Good luck.

Richard Lannon is an international business and technology industry veteran turned corporate speaker, facilitator, trainer and advisor. He specializes in aligning the enterprise and technical skills to common business objectives. Richard helps organizations and professionals identify what’s important, establish direction and build skills that positively impact their bottom line. He provides the blueprint for your organization to be SET (Structured, Engaged and Trained). His clients call him the SETability Expert. He can be reached at [email protected] or 403-630-2808.

Enterprise Analysis: Process or Content?

Written by Terry Longo on January 31, 2008. Posted in Articles.

In earlier posts, I have been reasoning that the IIBA and BABOK are on their way to defining a generally applicable framework for requirements management best practices, and that the BABOK 2.0 will be the first significant manifestation of the distinction between process (the requirements life cycle) and content (the nature, or domain, of the requirements being managed).

Viewing the requirements management life cycle in that way, however, requires us to scrutinize the way in which Enterprise Analysis (EA), as currently defined in the BABOK, fits in:

EA is content because it is carried out specifically in the domain of business planning and business strategy.
EA is process as well, because it is a crucial first step in the requirements life cycle.

The question becomes: is there an EA-like step in the requirements life cycle within other domains? Let’s explore this question by considering another domain, that of enterprise e-learning infrastructure and delivery (there are many other domains we could choose as well). From the business strategy point of view, this is a tactical and operational aspect of the enterprise. But from the e-learning director’s point of view, there is, of course, strategy involved, addressing questions about workforce trends, globalization of the enterprise, the presence of electronic performance support practices, learning-related data privacy, and many others.

So the e-learning director must:

Create and maintain the e-learning architecture
Conduct feasibility studies of e-learning infrastructure and delivery solutions
Determine the scope of e-learning infrastructure and delivery projects
Authorize the initiation of those projects
Interface with the project team to manage the projects’ value, track benefits, manage change and risk, etc.

Hmmmm. Looks a lot like BABOK’s Chapter 2: Enterprise Analysis. Which is the point being made. “Enterprise” is the content. “Analysis” is the process. An e-learning director reading BABOK Chapter 2, while pretending the title was “E-Learning Infrastructure and Delivery Analysis” would get some great guidance.