Practical Analyst

Give ‘em Pictures!

2010-02-03T17:45:33-08:00

The longer I do this “business analysis” thing, the more convinced I become of the notion one of the surest ways to ensure project success is to get “pictures” in front of the users/stakeholders as early in the process as possible.

Kulak & Guinney tell us that,

The requirements specification does not provide the users with a cohesive view of what the system will accomplish; it is merely an itemization of each of the various functions.

The “itemization” has its use, but for customers it is a little like going to the restaurant and seeing recipes for the various items on the menu instead of images of the delicious end product. I might be able to tell from the recipe whether or not I’d like it, but I would have a much better idea if I had that picture.

As a customer, I don’t want to have to work that hard to tell whether or not I like what I see, and as a customer, I shouldn’t have to.

Bottom line – we often make our customers work much harder than they should have to in order to get a contextual view of what we think the end product will look like.

And when I say “pictures” I am referring to rough sketches, mock-ups, diagrams, prototypes – any tool that takes requirements and puts them in a form that is more familiar to our customers.

Robert Wittig goes a little more into the psychology behind how we process an essay as opposed to a picture (emphasis mine).

When we read an essay, we attack it a few words at a time, we do not consciously try to ’see’ the whole essay at once, the way we at first view a picture. There is an interesting difference here, in how our consciousness manages these two different tasks. With the essay, it starts with the words, the small bits of information, and slowly builds upward toward full understanding of the whole. With a picture, it starts with the whole picture, and gradually works its way down into the details. Our consciousness cannot hold either an entire essay or an entire picture in its consciousness at one time. For some reason, it prefers to approach these two tasks from opposite ends.

Wittig’s description of how we process pictures differently than words is precisely why it is so important to give users visual models early. We don’t want them to have to begin with the details and try to construct the whole of the product mentally. As it is, natural language is ambiguous and can be interpreted in many ways even when we take every care to minimize ambiguity.

Instead, let’s provide a rough sketch of the big picture – something that resonates with the user or business stakeholder, and something they don’t have to work so hard to understand – and iteratively refine it until it becomes a solution that will delight the customer. Visual models are much less ambiguous than words alone.

To be clear, I am not inferring that we ought not do requirements in written form, only that they should be supplemented – as early as possible – with other models that help customers understand them. As the visual models are refined, the functional specification or use case is refined in serial.

A customer is much more likely to engage in the review process when they feel that they understand the materials they are asked to review. When we hand them a BTD (big thick document) and tell them we want their feedback at the meeting in 3 days, we are doing them and ourselves a disservice.

After all – how much do you, as an analyst, look forward to peer-reviewing your teammates 190 page document that’s packed to overflowing with colorless “system shall” statements?

More to come on visual models, and maybe a few ideas on how they can be used to in concert with textual specs, but I wanted to get this out sooner than later. Been much too long since I last posted!

Quoteworthy: John D. Rockefeller Jr.

2010-01-25T17:41:47-08:00

The secret of success is to do the common things uncommonly well.

- John D. Rockefeller

Quoteworthy: Jim Brosseau

Quoteworthy: Blaine Lee

2010-01-14T17:54:37-08:00

Before you attempt to set things right, make sure you see things right.

- Blaine Lee

No related posts.

Quotable: Arnold Toynbee

2009-12-01T18:24:29-08:00

Apathy can be overcome by enthusiasm, and enthusiasm can be aroused by two things: first, an idea which takes the imagination by storm; and second, a definite, intelligible plan for carrying that idea into action.

- Arnold Toynbee

Quoteworthy: The bitterness of poor quality

2009-11-12T19:23:36-08:00

The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten.

– Anonymous

Agile Teamwork – what BA’s need to know (Guest Post)

2009-11-04T18:04:04-08:00

I hope you’ll enjoy this guest post (our first ever, actually) by Rowan McCann of Bright Green Projects. - JB

Introduction

Back in the 90’s self-managed teams were all the rage but they had a high rate of failure mainly because team members lacked people skills. These ideas of self-managed teams were borrowed by the Agile movement when in 2001 they formulated a ‘new’ way of working, based on Agile principles. These principles value individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.

For these ideas to work in practice Agile team members must know something about teamwork and this means understanding a lot about human behavior and why people do the things they do!

Agile team members are usually composed of highly skilled knowledge workers with strong values of Independence. Some are worth more to an organization than the people who manage them! Many software developers are quite introverted, preferring to interact with their computers rather than people. My own IT degree course hardly spent any time on people skills and nothing on the even more difficult concept of what people need to do to ‘self-manage’ into a high-performing team. I’ve had to learn this in the world of experience. I wonder how many readers find themselves in a similar position?

If you look at the Agile web space you’ll find that the emphasis is on ‘engineering best practice’ and tasks, rather than team processes. Many project managers, too, are used to old-school leadership where they are more comfortable with control and the power that goes with it. So for Agile IT teams to become high-performing it’s essential that, right from day 1, time is spent in helping the team to initiate the process of adaptive learning and this requires a focus on behavioral skills.

Rather than let Agile Teams try to reach high-performance by trial and error it seems to me that the first thing to do is for everyone to understand the behavioral characteristics of their team members. For a business analyst to be effective in an Agile environment they must understand a lot about people and how best to interact and influence them. A good starting point is to learn about the nature of teamwork and the preferences people have to engage with some tasks and not others.

The Nature of Work

A starting point for Agile Teams is to understand the nature of the work that all teams need to focus on. The Team Management Systems Types of Work Wheel identifies eight distinct ‘Types of Work’ that need to be undertaken by all teams, regardless of their industry. We have found this concept invaluable when working in the area of Agile Project Management.

The eight work functions are listed below, with the approval of Team Management Systems.

If you want to get valuable feedback about your current or future Agile Team we’ve put up a free questionnaire on our website. You’ll get a free 8-page assessment of what you think about your team’s performance, based on these eight Types of Work, or work functions.

Team Management Systems Types of Work Wheel

	The Advising function is associated with the gathering of information from all stakeholders and responding quickly to changing requirements. It involves keeping up-to-date with developments inside and outside the organization and passing advice on to others to help them in their work. It requires a transparent flow of knowledge of ‘what’ is going on and ‘where’, and a focus on ‘consulting skills’ so that information can be gathered quickly, accurately and effectively. A good Requirements Management System enhances this work function.
	The Innovating function involves generating new ideas and new ways of doing things. This requires the development of creative problem-solving skills so that the team remains one step ahead of its competitors. To do this well requires original thought, imagination and innovative thinking.
	The Promoting function is concerned with the identification of opportunities and the ’selling’ of these opportunities to others, both inside and outside the organization. It often involves the application of influencing skills and the making of presentations to others. It can also involve communicating the team or organizational ‘vision’. High visibility throughout the organization may also be required.
	The Developing function is associated with the turning of concepts into ‘reality’. Ideas are worked on to produce practical products and services. In many cases it may also involve developing workable and practical solutions when problems arise. Agile Teams need good analytical skills so that requirements can be quickly prioritized, enabling accurate estimates of iterations and burn down charts.
	The Organizing function involves organizing people and resources efficiently by setting clear goals and objectives and making team members accountable for their actions. It is also associated with the implementation of quick effective action when problems occur, so that the planned outputs are always capable of being achieved. In summary it’s the function that ensures that the work of the team is structured and focused towards common objectives.
	The Producing function focuses on outputs, ensuring that iterations are completed to high standards of effectiveness and efficiency. It’s the function associated with the regular delivery of releases and other services. It requires a systematic approach to work and an emphasis on the delivery of products on time.
	The Inspecting function requires an attention to detail and an emphasis on the monitoring of systems, contracts and outputs. It’s also associated with a focus on accuracy, ensuring that work outputs are always delivered to the right quality. This function is the classic control function where procedures are regularly monitored for their efficiency. It’s often a core feature of the iteration review process.
	The Maintaining function is a support function which ensures that proper standards of conduct and ethics are upheld and that quality is maintained. It’s also associated with supporting others in the team so that the team processes follow agreed ground rules. Personal conviction and loyalty are often important to this function as is an interest in helping others.

Work Preferences

For teams to be high-performing it’s essential that these eight Types of Work are done well. But Team Management Systems has discovered that rarely does anyone actually enjoy doing all of these functions. People show distinct ‘work preferences’ for maybe just two or three of these activities.

Work Preferences are dimensions of individual differences in tendencies to show consistent patterns of relationships, thoughts, feelings and actions in the work environment. Work Preferences determine the conditions we all set up to allow our mental and psychic processes to flow freely. Preferences are usually transparent and are often the first thing we notice in others – ‘He’s rather quiet, isn’t he?’ or ‘She never stops talking.’ Some people prefer to think things through on their own whereas others need to talk out loud to clarify their ideas. Preferences are readily visible to others and are usually the basis of first impressions.

When we are working to our preferences we set up conditions where our psychic energy can flow freely. If we are more extroverted we like work where there are lots of interactions with others, both inside and outside the organization. If we are more introverted, then we like conditions where we can work on our own with few interruptions and a minimal requirement for meetings. Under these conditions our energy can flow freely with minimal resistance. Just as electrical energy generates heat when it meets resistance so our psychic energy generates tension and stress when it has to flow through areas that are not our preference.

I have a preference to work in the Advising and Innovating areas on the Types of Work Wheel and I don’t really enjoy Promoting or Organizing activities, so wherever possible I’ll spend time thinking about new ideas or finding out as much as I can about the project.

It seems that the ‘Law of the Four P’s’ applies here. We all tend to practice what we prefer; for example you might prefer to play golf rather than squash. Therefore at any opportunity you are more likely to be on the golf course rather than on the squash court. The more you practice golf the more likely you are to perform better at it and maybe even become perfect. So it is at work. We all tend to Practice what we Prefer and over time we become more Proficient in the areas of our preference. This in turn gives us Pleasure from our work.

What happens in an Agile Team is that there’s likely to be an imbalance when you look at the work preferences of all the team members. If everyone is like me then there’ll be a tendency to give priority to making changes and incorporating the latest ideas. Teams like this may have the weakness of never tracking their burn-down charts!

Other weaknesses occur if everyone enjoys just Organizing and Producing. Your team may be well organized and on-target but is it really delivering what the stakeholders want or indeed need?

So, if your Agile Team is to be truly effective you must understand the work preferences of all team members and look at the preferences balance. It will give you an immediate picture of strengths and weaknesses, as far as teamwork is concerned. Information like this helps ensure that everyone’s work preferences are matched to the critical demand of the job they have to do. Where the match is high, our energy flows freely, we are more likely to enjoy our job, stress is lower and we feel happier at work. But all eight work functions must receive the priority they need and never be relegated to lower importance.

Is it possible to identify a person’s work preferences? Fortunately the answer is ‘yes’. Many years of research by Team Management Systems has led them to a reliable and valid way of doing this.

The Types of Work Wheel is a model about essential team tasks but there is a strong relationship with work preferences. For example people with preferences for extroverted relationships and creative information gathering map most often into the Promoting area of the Types of Work Wheel whereas those with introverted relationship preferences and practical information gathering most often prefer Inspecting work. Those who like analytical decision-making and prefer to work in a structured way show a bias for Organizing work whereas those with beliefs decision-making and a more flexible approach to the way they organize themselves and others enjoy Advising work.

The Team Management Wheel

The integration of the Types of Work Wheel with the work preference concepts led to the development of the Team Management Wheel.

The TMS Team Management Wheel

A person’s work preferences can be mapped onto this Wheel as a major role preference and two related role preferences. Thus someone might show a preference as a Creator-Innovator with related roles of Thruster-Organizer and Concluder-Producer, or as a Controller-Inspector with related roles of Concluder-Producer and Upholder-Maintainer.

Here are some general characteristics of each sector:

Reporter-Adviser:	Prefers gathering information and likes to fully understand situations before acting
Creator-Innovator:	Enjoys thinking up new ideas and new ways of doing things rather than focusing on delivering outputs on a regular basis.
Explorer-Promoter:	Like to take ideas and promote them to others, not worrying too much about any details involved.
Assessor-Developer:	Enjoy analyzing and developing different possibilities before decisions are made
Thruster-Organizer:	Like to make things happen and get results rather than ‘waste’ too much time debating issues
Concluder-Producer:	Practical people who like to carry through things to the end by working to a plan
Controller-Inspector:	Quieter, reflective people who enjoy the detailed side of work and like dealing with facts and figures.
Upholder-Maintainer:	Enjoy working in support of others ensuring that tasks are delivered to high standards

Using the Team Management Wheel to Improve Teamwork

There are many ways to use the Team Management Wheel to improve Agile Team performance. Some of these are highlighted below.

Self-understanding

Receiving detailed feedback on which team roles a person is likely to prefer helps them realize why they emphasize some team activities but ignore others.

Team balance

If all members of a team map unevenly around the Wheel it helps explain why some team activities are ignored. After all, we tend to give priority to those tasks we like doing. If there is a team imbalance then everyone knows that an extra effort needs to be made to make sure that less-liked team activities are done well.

Work allocation

Knowing what team roles someone prefers can help with the allocation of tasks. For example, giving an Explorer-Promoter tasks with a high need for detail is probably an unwise move. Asking Reporter-Advisers to work in a job that requires a ‘thrusting’ approach to organize projects and deliver results on time may cause them unnecessary stress.

Colored meetings

Many teams use the concept of the Team Management Wheel in planning meetings. Green meetings focus on information and ideas. Yellow meetings explore options and discuss relevant ‘promotions’. Red meetings are all about planning for action and results. Blue meetings are review meetings to go over the detail. In this way adequate time can be assigned for four distinct but important features of teamwork.

Understanding others

Different roles on the Team Management Wheel see the world in different ways. As a result, team members tend to make negative attributions about those on the other side of the Wheel. Explorer-Promoters may see Controller-Inspectors as dull, boring, pedantic and detail oriented. Controller-Inspectors in return may see Explorer-Promoters as loud-mouthed, waffling and with little substance. It’s a natural human tendency to look negatively on those who are ‘different’. However all roles are necessary to get the best from a team because, often, it is out of diversity that the best solutions arise. Learning how to appreciate individual strengths can be achieved by use of the Team Management Wheel.

Linking

I haven’t mentioned Linking yet but it’s probably the most important idea on the Team Management Wheel and the subject of an article on its own. It’s an activity responsible for integrating and co-coordinating the work of the team. It’s not a preference but a set of important skills that applies individually to team members and collectively to the whole team. Ideal Agile Teams have a low level of leadership control and a high level of autonomy. In these situations team effectiveness largely depends on six key skills of People Linking. These are the skills of Active Listening, Communication, Problem-solving and Counseling, Team Relationships, Participative Decision-Making and Interface Management.

For People Linking to be effective it’s important for all Agile Teams to establish a set of ground rules. These are an agreed set of acceptable individual behaviors that define how team members will interact. Usually they comprise 10-20 statements that are posted in the team meeting room or on the Agile Project Management Platform, agreed at the start of the project and reviewed after each iteration. If a team member is unhappy with a particular team process then it’s easy to open up a discussion just by referring to the relevant ground rule which everyone has already agreed to. Conflict is often avoided by this simple process.

White meetings are Linking meetings, often referred to as the daily 5-minute stand-up meeting when teams are co-located. If you’re interested, I’ll talk about Linking in a future article. In the meantime try out the free Agile Team Performance Questionnaire.

Bright Green Projects is a cloud-based Agile Project Management Solution, developed by a team of Management Consultants with 10 years experience working internationally. Take a look at http://brightgreenprojects.com/overview to watch a quick video.

Quoteworthy: Karl Popper

2009-10-22T15:14:00-07:00

It is impossible to speak in such a way that you cannot be misunderstood.

- Karl Popper

No related posts.

Quoteworthy: Kulak & Guinney

2009-10-12T17:57:34-07:00

An appropriate and complete requirements specification does nothing to ensure a successful implementation; however, it makes it possible.

- Kulak & Guinney

Quoteworthy: Joseph Joubert

2009-10-05T18:30:10-07:00

Words, like eyeglasses, blur everything that they do not make more clear.

- Joseph Joubert

No related posts.

“Cascade”: Q&A with David Wright

2009-10-01T17:35:11-07:00

David Wright is no stranger to many who participate in the various online business analysis-related forums and online communities. He’s been in the business for over 25 years and, during that time, has accumulated quite a bit of practical knowledge and insight.

Not long ago, he decided to put pen to paper and share some of that accumulated knowledge in Cascade; a guidebook using a framework of 13 principles to describe “better practices for effective delivery of information systems in a multi-project environment“.

I’ve read and enjoyed the book myself, and thought it’d be interesting to get a little background on Cascade and the thought process behind it.

With that in mind, I sent David a list of questions that you’ll find below along with his responses and a few of my own comments on the book.

Cascade is a pretty unique title. How did you come up with that?

It’s a play on Waterfall methodologies. I always thought Waterfall was a misnomer, because of the standard criticism of it being slow; I have been to Niagara Falls a few times, and it has never looked slow. A “cascade” is usually visualized as a small but very quick moving thing, and it just clicked with me when I was looking for a high-concept name for what I was writing about.

What motivated you to write Cascade? What are your goals and aspirations for it?

It was something I had to get out of my head and down on paper (or Word doc). I have been working in information systems long enough that I had a set of “rules of thumb” that helped me be successful while avoiding failures I have seen before. I was having a conversation one day with a friend about methodologies and manifestos and what they really accomplished, and it dawned on me that my own experiences and “rules” addressed the same topic. It took me about a half-hour to write out the first cut at what would become the practices in Cascade. After that, it was a matter of fleshing it out with examples and war stories. I guess it comes to that old adage of writing about what you know.

My goal now is to share Cascade with any and all who might find it of interest, and who might be helped by it. To be honest, I did not think about this much while I was writing it, I just needed to get it written. It is a vast marketplace of ideas out there, so achieving that goal is the challenge now; writing it was the easy part!

The book specifically addresses multi-project environments. What caused you to focus there?

It is the reality that most any IT shop faces, but when you want to find some methods to help deal with that reality, what you will find most in the market is methodologies that describe how to best deliver a single project. Most of the time in my career I would be working on several projects at the same time, reflecting the fact that the IT departments I worked in were always executing many projects at the same time. There was never the luxury of doing one project at a time, get it done, and then start another one. There are always too many demands on IT from all parts of the rest of the business to allow that. So constantly working in that environment lead to the experiences that drove out my rules and practices.

There are lots of good practices when it comes to IT delivery. Just curious, how did you whittle the number you addressed to the 13?

It was actually built up to thirteen. I started with my initial draft list, and added a few more to address certain experiences, and it settled down at 13. Anything else I wrote after that fit into one of the thirteen. At this point, I like the number itself, at least for now. I am still working on projects every day, so I may have some more practices to add down the road.

Who would you say would benefit most from reading it?

I would like to think that almost anyone involved in multiple projects at a time could find some benefit, from project sponsors through to testers. I suppose the main audience is IT Managers who are responsible for a group of projects, or manage the people who work on many projects. Most of my actual work over the years has been in Business Analysis with some Project Management when needed, so that’s in there too. The idea of the separate practices is that you only need to read those that affect your work the most, then hopefully readers will take in the rest after that.

What about Cascade are you most proud of or has given you the most satisfaction?

As a Business Analyst, I have done a lot of writing over the years, but always for a project purpose: Project Charters, Business Cases, Requirements Documents, and so on. Cascade is something I wrote for myself, no methodology or templates or standards to drive what I wrote. So, seeing it done was a moment of pure pleasure of accomplishment. I had never pictured myself as an “author”, so to be one now is a good feeling, I highly recommend it to anyone who thinks they might have it in them.

My Thoughts?

First of all, I appreciate David taking the time to respond to my questions, and enjoyed reading the responses. I hope you did, too.

As I said above, I read Cascade and really enjoyed it. It was a quick, 100 page read with a light, familiar tone and a nice pace.

I wouldn’t say David has invented any new principles or coined any new buzzwords with Cascade, but he does provide some specific and sound advice on how familiar principles can be put to good use in a multi-project environment.

I think it’s a good resource and I do recommend it to business analysts particularly for the useful way it ties principles of business analysis in with architecture, project management and resource management principles.

Availability

Cascade is available at Amazon and other various online booksellers. If you’d like to get more acquainted with David, look him up on Twitter or check out his blog (which contains quite a few Cascade teasers if you look back through the archives).

Have you read Cascade? If so, what were your thoughts? What other recently-released books would you recommend as a good read for BA’s?

No related posts.