Tag: Success

Soft Skills Sustain Success

Written by Marcos Ferrer on December 14, 2010. Posted in Articles. 2 Comments on Soft Skills Sustain Success

Like any other “business case”, this one starts with a business problem or opportunity. The problem is that a large percentage of business “change” projects (most involving IT) fail to meet their goals. In too many cases this failure is total.

Failure, including dismal failure, is NOT theoretical – examples abound. The IRS has spent 10 billion dollars twice on two projects over two decades without achieving their “business” goals and objectives. The Department of Homeland Security is scrambling to save some of the $110 million they spent on projects to track “Guest Visitors” – projects that resulted in unusable code and flawed requirements documentation.

Such problems are not limited to government ventures, nor are they ascribable to “bad ideas” or “less brilliant” practitioners. Blackberry was the dominant handheld smart phone for years, and is now struggling to remain relevant. Search engines come and go, and even Google feels the risks (patents expire, and winners are not always beloved, and lawsuits continue to settle behind the scenes).

Countless smaller, un-newsworthy projects fail every day, some to be abandoned and others to be repeated. Most common of all – many projects that are out of immediate public view “declare victory”. This happens in spite of the fact that everyone involved (especially the users of the “change”) knows the projects are challenged or even failures. The Space Shuttle program (not just the two failed flights) is one extremely public example (no comments please, unless you first look up the original stated goals and objectives of the Shuttle program).

OK, this is just a blog, so I am going to stray for a minute, for BOK sake. Some say that Google’s brilliance is not their patented search technology, but is actually a “business rules” based success (read the BOK technique of “business rules analysis”). Much of Google’s revenue is generated from a business policy of aggressively and consistently using other people’s intellectual property (search Ford, find Chrysler AdWords) combined with knowledge of the browsing public’s “private” behaviors and actions to generate revenue. The simplicity of their interface is quite brilliant, but exists only to hide the “back room”, where the deals get made.

Then we have the example of the iPad – an Apple product that people buy just to find out what it does! This is no small feat – “tablet” type computers have been tried repeatedly and have always failed in the past. Look at GE, which has a sustained success record that is the envy of many organizations and a history going all the way back to Thomas Edison. Consider the Post Office and the Social Security Administration and even your local Department of Motor Vehicles – these institutions have all improved operations and automation, even as other agencies have struggled. What about all the “un-newsworthy” projects that succeed (G.E.’s latest toaster is probably profitable, IIBA’s outsourced delivery of online CBAP tests has resulted in 400% growth in CBAP test takers, the U.S. Mint’s online coin sales and automated subscriptions seem to work for most people).

What is different? Is it just pure luck? If only luck is involved, we can quit right here. Assuming that there is more than luck involved, can we try to understand the difference?

Let’s try some Root Cause Analysis. According to an oft-cited 1995 Standish Group report (the “Chaos” report), projects that fail or succeed seem to fail or succeed for reasons like the following, organized according to how they seem to relate to each other:

FAIL	SUCCEED
Lack of User Input (we take “User” to mean “Stakeholder”, a more “modern term and important concept)	User (Stakeholder) Involvement
Incomplete Requirements & Specifications	Clear Statement of Requirements
Changing Requirements & Specifications
Lack of Executive Support	Executive Management Support
Lack of IT Management	Ownership
Technology Incompetence	Competent Staff
Lack of Resources	Hard-Working, Focused Staff
Technology Illiteracy
Unrealistic Expectations	Realistic Expectations
Unclear Objectives	Clear Vision & Objectives
Lack of Planning	Proper Planning
Unrealistic Time Frames
Didn’t need it (the project outcome) any longer	Smaller Project Milestones
New Technology
Other	Other

Let’s start with “Lack of User Input” vs. “User Involvement”. I will use a table structure in place of the “fishbone” diagram for ease of reading (and writing!).

FAIL	SUCCEED
Lack of User Input because:	User Involvement
Users aren’t given time to provide input because: No one asked for their time Inaccurate planning & estimation It isn’t worth their time It isn’t a priority for their manager Too much time is (has been) wasted in the process	Users are given time
Users don’t want to cooperate or give bad information because: They are afraid for jobs and stability They are loyal to friends and secrets They are obligated by Union loyalties They don’t trust the process They don’t trust the organization Their jobs ARE ACTUALLY at risk	Users want to cooperate and give their best information
There are no Users because: The project involves a new invention The outcome is invisible to users The project is new to the organization The users have all quit The users were all hit by a truck	Project gets cancelled or it is handled as a “research and development” project or an internal “systems” project or leadership is changed and the users rehired.
Users don’t do anything or can’t because: The current process is completely broken The current process exists to create jobs Users are not asked to do anything Users are punished for taking action	Hence the project, hopefully not in place of improved leadership.
User input is never sought because: There are no users (see above) No one knows or believes that it matters The users are too expert for the project team to understand	User input is always sought
Users cannot be observed because: Thinking is impossible to “observe” Work rules, law or social convention forbid observation User behavior changes under observation Cost of observation is high (deep sea divers) Users don’t do anything (see above)	Users know what they do or can be observed
Users don’t know what they do because: It is not easy to explain thinking in words – explaining how I wrote this is much harder than simply writing it It is not easy to explain actions in words (explain “hitting .330 in the Major Leagues, as opposed to the more general process of merely “hitting a baseball”). Users may have invented their own processes, without enough understanding to document (“it just works”) What users do is complex and cannot be explained to non-experts Users don’t repeat any process in their jobs Users don’t do anything (see above)	Users know what they do or can be observed

Now, let’s keep it simple (frankly, I am out of time and space for this blog). Given that we know some success and failure factors, do we really need to keep digging into causes of causes and ultimate causes? If a logger were failing to cut logs, we would expect leadership (not the same as “the leader”) to intervene and help fix it. If a logger were failing to cut logs on Mars, we would expect leadership to intervene and put a stop to the wasted effort.

When we build lists like “Unclear Objectives”, but fail to clarify objectives, this can only be a failure of leadership, unless we enter a new society where “underlings” give themselves their own job, and raises too. To quote one of the participants in the Chaos study, a programmer who was interviewed as part of a focus group:

“Sometimes you have to make a decision you don’t like. Even against your own nature. You say well, it’s wrong, but you make that decision anyway. It’s like taking a hammer to your toe. It hurts.”

And another, an IT manager:

“Probably 90% of application project failure is due to politics!”

Apparently failure doesn’t hurt enough, because to challenge destructive forces one must risk displeasing one’s overseers, and that is far more painful. Only leadership, starting from above, can change this, and only when it values leadership over power.

Once again the BA profession must face it – while some problems cannot be solved with mere leadership (you can’t yet code up a physicist, or an artist, or a fair judge), the majority of problems can be traced to poor leadership, and not just from the bosses.

If you can face the challenge, leadership training, soft skills, communication, even sales – these investments will pay you the most. There is no lack of intelligence (the engineers knew the Space Shuttle was at huge risk), only a lack of influence by intelligence.

If we can stop just knowing what we know, and embrace the need to sell and teach and politic for what we know, we have the best chance to do good work and be recognized.

Keep up the good work, all you BA folk!

Don’t forget to leave your comments below.

Where Do User Stories Come From? Part 2

Written by Robert Galen on November 9, 2010. Posted in Articles.

In my last post I introduced the topic of User Story Writing Workshops. These are planning meetings where a product owner can gather a team (existing or potential) together where they collaborate to create a list of user stories to be used in seeding a product backlog.

It’s a wonderful technique for generating loads of stories-quickly! It also has some serious side-benefits that I think are valuable as well. But, enough of that…

Let’s Get to Writing Stories

There are many ways to attack story writing in groups. I’ll be emphasizing my preferences here, but don’t let that limit your own approaches. The key element is to:

Generate as many stories as possible
Across as broad a spectrum of features / work as possible
As quickly as possible
And along the way, collect as much Meta-Data as you can

I like to have the roles drive the brainstorming, so for each role, I’ll allocate 10-15 minutes of story writing time. Usually, I start this with the entire group-so everyone is writing. I’ll “call out” each story as I collect it to let everyone know what’s being written and to reduce the number of duplicate stories produced.

Once you have a large set of stories, I like to stop action (writing) and get the team engaged in “cleaning up” the stories. If I’ve posted them on a whiteboard, I’ll invite the entire team up to the board to start removing redundant stories, consolidating stories where there are obvious relationships, and writing new stories to fill in any ‘gaps’.

Often I’ll oscillate between writing as a group and this collaborative clean-up effort. It helps to keep the whole group engaged in the process and it maintains energy and focus in the meeting. Once you’ve developed stories for each one of your roles, you’re essentially done with “Round #1”, Then you move onto massaging (ordering in time sequence, considering risk, filling in gaps and dependencies, etc.) in your stories.

The Chess Analogy

Once you have a fairly healthy list of stories, I like to spend a fair amount of time on ordering them. This gets everyone thinking as soon as possible about execution. And because we’re thinking of overall workflow instead of pure feature development, another rich set of stories soon emerges related to things like quality and testing, release preparation, design and architecture, prototyping, UX design, software packaging, etc. You know, all those things required to get the project ready for customer deployment need to be captured in story-form as well.

In order to do this, I ask the team to place the stories in largely three buckets: opening moves (early stories), middle game (middle – mostly execution based stories) and end game (stories focused towards completion and delivery).

While this is truly not a WBS or Gantt chart, it does serve to get the team organizing the story mix into a rough workflow and begin thinking of linear dependencies and breaking things down for construction and integration. So the flow is illustrated below-

Overloading Your Stories, Meta-Data

Perhaps it’s just me, but if I’m taking time from a team for a story writing workshop, I want to maximize the data that I collect. To do this I usually ask the team to overload their cards with other bits of useful information that I might (keep in mind might) use later. For instance; Adding estimates, in either weeks or story points, can be a useful exercise at this point. This becomes the starting size estimate for each story and even though it’s simply a guess, it does help to communicate size and level of effort across the group.

Another thing to consider is team assignments, especially those for any specialized skills. For example, if there’s a database story that the entire team knows only Sally can effectively handle, then we might say that on the card. Or if the card requires a skill that we don’t currently have on the team, then specifically identify that gap.

I try to avoid any notion of “tasking assignment” at this point, so don’t do this for every story. Just mine these connections as a natural consequence of the writing.

Related to this point is the notion of capturing dependencies and risks. Again, we’re just writing our thoughts down on Post-it Notes, so ask the team to note cross-story dependencies right on the Post-it Notes. You should also visually orient the stories to be “close together” on your board. And while the team is collaborating, I always ask them to identify risks as they go along. I usually maintain them as a growing risk-list off to the side.

I find that this sort of meta-data gathering enhances the quality of the workshop, but also reduces the time it takes for later processing of the stories into a Product Backlog. This data can be equally valuable as the stories themselves.

Finally, What’s Next?

Once I have the “opening move” stories defined, I usually will ask the team to do a bit more detailed expansion around these early stories. The logic goes that while I have your time and attention, why don’t I leverage it a bit more to increase the depth of visibility into high priority stories. This also serves to set the stage for “next steps” immediately following the workshop. So dig into the details on your highest priority stories.

Wrapping Up

So there you have it! By investing perhaps a half day of time, you can come out of a User Story Brainstorming Workshop with a wealth of information. You have stories. You’ll have a view to workflow, what needs to be done right away, and what’s deferrable. You’ll have a sense for key skill stories and for dependencies and risks. And you’ll have a solid view towards next steps.

But most importantly, your team will have created a “shared view” of their overall project. I’ve found this outcome to be critical when the team starts to iteratively attack the work. Since everyone contributed collaboratively to the overall scope of the project AND contributed to workflow details, they’ll have an innate sense of what is needed and where things are headed.

How cool is that?

Don’t forget to leave your comments below

Interrogating the Business Analyst Process to Discover Your own Value

Written by Laura Brandenburg on September 14, 2010. Posted in Articles.

One of the ways we can unknowingly hold our careers back is failing to understand and communicate our value effectively. Many of the business analysts I work with in their job search and career development initially lack an appreciation for how they contribute to the organization’s bottom line.

There are two common challenges that I see:

Failure to understand how business analyst activities tie to clear business objectives.
Failure to fully appreciate the value of the contributions they make as individuals.

In an earlier Business Analyst Times article, “Think “I” Instead of “We” When Talking about Your BA Career,.” I’ve already touched on point #2 above. Today I’d like to discuss how an intrinsic focus on business analysis activities unframed in a business value context can be career-limiting.

In an often-quoted article from CIO.com the value of the business analyst was cast in relief:

“For two decades, the CIO has been viewed as the ultimate broker between the business and technology functions. But while that may be an accurate perception in the executive boardroom, down in the trenches, business analysts have been the ones tasked with developing business cases for IT application development, in the process smoothing relations among competing parties and moving projects along.”¹

This statement speaks to a business-focused value of the business analyst. From an executive perspective, business analysts are valued because they help contribute to successful projects that have a solid business case. They are in the trenches ensuring that IT investments create value for the business.

However, oftentimes we see and hear business analysts talking about their value in terms intrinsic to the BA process. They focus on what we do as business analysts over and above why we do it. For every what, there is a why. And one of the best things we can do for our careers is to interrogate our own process with the same rigor with which we might challenge the process our stakeholders use to complete their work.

For example, one of the guidelines for writing textual requirements from the BABOK® Guide is “using consistent technology”. This is a worthwhile attribute and we all know that any decent business analyst will use terms consistently throughout their requirements specifications. But “using consistent terminology” is an answer to “what we do” or “how we do it”. It does not answer “why do we do things this way.” Let’s interrogate our own process to discover the why:

Interrogator: How does “using consistent terminology” create value for our organization?

Business Analyst: It reduces confusion about requirements.

Interrogator: Why does that matter?

Business Analyst: Well, if stakeholders are confused about requirements, we might spend extra time validating the requirements.

Interrogator: Why does that matter?

Business Analyst: Stakeholder time costs money.

Interrogator: Why does that matter?

Business Analyst: It means that creating the requirements for the project costs more than it should. If we use consistent terminology in our requirements, then we should be able to complete our requirements cycles faster. Oh, and it also means that we’re less likely to build the wrong thing and have to waste development resources reworking the system.

Interrogator: Nice!

Executive Level Summary: Business analysts help reduce the costs of project implementations by bringing clarity to the requirements. One way they do this is by using consistent terminology in their requirements.

Any activity we do can be diagnosed in this way. But sometimes the answers are not quite so flattering. Let’s interrogate the infamous “software requirements specification.”

Interrogator: How does “creating a software requirements specification” create value for our organization?

Business Analyst: This document tells us everything we need to know about building the system. Sometimes its 50 or 60 pages long. We’re really detailed.

Interrogator: Why is that important?

Business Analyst: Well, if we don’t document everything, we’ll miss something.

Interrogator: I can see that how it’s important not to miss something. How does the document ensure we don’t miss something?

Business Analyst: Well, we conduct a walk-through with everyone that needs to know what’s in the document and everyone that will be building what’s in the document. That way we know it’s complete.

Interrogator: Why does the walk-through ensure that nothing is missed?

Business Analyst: [Blank stare]

Now, your answers might be different. Maybe your software requirements specifications are required for regulatory reasons or you’ve found a solution to organize a walk-through of a long document that ensures completeness (I haven’t).

The point is not so much to pick apart a process that receives an almost constant beating. The point is to challenge you to evaluate your process with the same rigor your interrogator might do. What if this interrogator was your CFO or an external consultant who had promised you boss to find ways to reduce the costs of building software? Would you be able to justify the activity is worth your effort and the effort of your stakeholders? And, even if you could, are there other approaches to the same problem that would work just as well or better?

My challenge to you is to begin your week by looking at your calendar and to do list and asking yourself “why” for each significant item on the list. If you don’t know the answer, start researching it with your peers and your manager. Focusing on “why” is one of the most impactful career habits you can develop, both in becoming a promotable business analyst or in framing up your applications for your next job. We do it in our projects, why not also do it for our careers?.

1 “Why Business Analysts are so Important for IT and CIOs” CIO Magazine.

Don’t forget to leave your comments below

Laura Brandenburg is a business analyst mentor and author of the free “3 Career Habits for Successful Business Analysts“, a primer to becoming a promotable business analyst. She hosts Bridging the Gap, a blog helping business analysts become leaders and advance their careers. She has 10 years of experience leading technology projects and has helped build business analyst practices at four organizations. If you’d like to learn more about discovering and increasing your value, including an ROI framework for business analyst activities, additional career habits that help you increase your ROI, and techniques for communicating your value to stakeholders and managers, check out Laura’s upcoming BATimes webinar.

Working with Business Analysts Made Easy

Written by Mark Jenkins on September 7, 2010. Posted in Articles.

Over the last few years, many people have asked me for tips, techniques and skills you should develop when managing a group of business analysts. This article is an informal list BA managers might consider, especially if they are transitioning into management from a Business Analyst role.

Develop a BA Process

Provide a framework to which all your BAs work. Not only does this give them a consistent approach, but you a get a consistent way to assess their progress. Business stakeholders and IT staff should recognize a similar pattern in every project. In doing this, you are also training your stakeholders to think like a BA. After repeated exposure, they can foresee the next steps and come more prepared to meetings and projects.

Develop Consistent Tools and Standards

One of the worst things for a business user or developer to see is different documentation standards from each BA. I insist that everyone uses standard templates and adopts a consistent approach to diagrams and other supporting information. Be sure to make your templates flexible and try to refrain from producing overwhelming or heavy documents. I encourage BAs to try to separate documents as logically as possible. Having a functional requirements document full of use cases, mockups, data specifications and a report catalogue can quickly become a 100 page+ document and business and technical staff struggle to read it.

Get Involved in Planning Projects and then Leave the BA to it

One of the realizations when you move into management is that you cannot be everywhere all the time. More importantly, you understand that you don’t want to be everywhere all the time! It’s challenging when you move from being responsible for your own projects, running meetings and getting involved in as much detail as you like, to only having time to view projects from the periphery. One of the methods I use to stay involved, but not participate on a day to day basis, is to work with the BAs at the start of the project, to ensure they plan their efforts and evaluate the scope of their projects in a consistent and clear manner.

The scope evaluation typically takes the form of what I refer to as Power Verbs. These are the action points that you can then use to maintain your sense of the project. For example, if the project was to move house, the Power Verbs might be Investigate, Decide, Prepare, Pack, Move, Unpack, Recover. I would then spend time to expand each Power Verb into a series of action areas. These action areas then allow the BA and the manager to ensure that a project starts off with a clear understanding of potential scope. For the manager, this affords an opportunity for context any time they need to get involved, because they a basic understanding of the overall process.

By overseeing planning and providing a solid framework within which the BA can operate, the BA is free to use their own techniques and methods, while the manager is comfortable knowing the scope will be addressed.

Resource Your Team Well and Review it Constantly

One of the major areas of challenge for a manager is resource management, especially in fast paced environments. I use a tried and tested technique which I documented here, it has not failed me yet. However, regardless of which method you use, you need to find the right resources and resist the temptation to take on projects or problems yourself. It is not ideal if you assign a BA to a project and then they have to leave a few days later, because you forgot they were required on something else. I find that BA’s max out on 2 large projects or 3-4 smaller projects at any one time, any more and they lose the consistency needed to stay focused and add value. You will also want to track the time spent utilized vs. down time, as this will be a key measure in your demonstration of your success in resourcing your team.

Find a Way to Reduce BAs Moving from Project Area to Project Area

If a BA has to move business areas on each project, you will easily waste time unnecessarily as they need to ramp up to a new environment each time. To prevent this, assign your BA’s to a business area or project type and try to keep them there. As the BA gains experience they become more familiar with the stakeholders, processes and systems, they will reduce ramp up time to zero and add more value to the project. On a yearly or bi-yearly basis, try to switch the BAs around to keep them learning and developing.

Over Invest in Recruitment Efforts

Many managers are nervous about interviewing and recruitment and as a result hire the wrong candidates. If you are hiring BA’s, think about the qualities your candidates should demonstrate and try to use behavior based questions that call for specific examples. I will typically ask BA’s to do a live iteration exercise or some other activity relevant to the job to get a better sense of their real world performance. It’s better to take your time to hire the right skill set than to rush and hire the wrong person.

Don’t Forget the HR side

Being a good manager requires skills that you may not have developed as a Business Analyst. To make it harder, BA’s are usually smart people and need a specialized management style. They generally hate micro-management, are creative, and by nature are always finding problems that you’ll need to develop into opportunities. Encourage a collaborative style and get them involved with how the group progresses.

Meet as a Team Regularly

Schedule a weekly or bi-weekly meeting to talk about projects and status. You’ll find numerous instances where BA’s are overlapping or suffering from a similar pain point. Talking about these issues in a group format allows everyone to learn for very little effort.

Develop the Skills of your People to Improve Team Performance

Invest in team training but identify the skill deficiencies at the individual level. There’s really no point to sending your whole team on a use case course, if only one of them doesn’t know how to do them. Also, get creative and proactively look for free webinars and events. One of the easiest ways to develop a sense of where each BA is at is to create a competency model, specific to your process and to your environment. Use the competency model to guide where a BA needs help and improvement. It is also a great tool for managers to show leadership how the group is developing over time.

Establish Membership with the IIBA

Sounds expensive but it isn’t at all. $95 per BA for the year and you have access to a wealth of information and potential connections. The corporate membership is also a great deal and isn’t that much more expensive.

Don’t Forget your Stakeholders and Customers

As a manager, you represent your group to the wider organization. You will need to develop and maintain partnerships with your customers, especially the challenging ones. Enterprise Analysis is a great way to stay engaged as a BA Manager, but inevitably you are now going to focus on your relationships with stakeholders, ideally higher up in the organization. Don’t forget that the judgment of your success often lies in the perception your customers have of your group. It’s helpful to research how effective account, product or relationship managers operate, to give you some tips and techniques in this area.

Also, don’t forget to get to know your new peers. Build new relationships with the other managers you work with. Find out the pain points they have with your team and offer to help by changing things that aren’t working.

Change your Relationship with your Manager

You will now have a different working relationship with your manager, possibly even a different manager entirely. You have to recognize that there is more of a strategy element to the management role than was required for your role as a BA. Focusing purely on tactical and not strategy is going to quickly disrupt progress. One of the key documents to develop is a road map for your group, set some goals, establish a timeline, get all your team involved and then manage to a plan.

Remain Positive, be Enthusiastic, Lead by Example

As the leader of your group, your actions and demeanor have an instant impact on the moral of your team. Your staff will be looking to you for leadership and you need to respond accordingly. When you interact with BAs in project teams, live, breathe and demonstrate the development you want to see in them. Don’t forget to reward your staff for a job well done, even if all you can afford is a thank you, it’s a great place to start!

To conclude, while this article is not exhaustive list of everything you need to manage BAs (nor will that list ever be completed) but I hope it has given you some ideas. Remember, there is really no need to start from scratch as you mature your team and develop your management skills. The internet (Twitter, IIBA, Bridging the Gap etc) and people going through similar experiences are great sources of information. LinkedIn is also a great way to connect with colleagues, it’s also a really great way to recruit!

Don’t forget to leave your comments below

Mark Jenkins is the Associate Director of Business Analysis at KPMG. Mark leads a team of 20+ Business Analysts at KPMG in a Center of Excellence format. Prior to KPMG, Mark established a highly successful Business Analysis group at Internet Security leader Websense. Mark draws on his 8 years of Business Analysis experience, including numerous CRM initiatives and a wide range of projects, across all business areas. He can be reached at [email protected] and on twitter www.twitter.com/JenkoUK. Mark is also the Regional Director for the Americas Eastern Region at the IIBA and will be speaking, as part of a panel discussion, on Building a BA Career Center of Excellence at the IIBA Conference in October

Five Rules for Project Success

Written by Elizabeth Larson on August 10, 2010. Posted in Articles. 1 Comment on Five Rules for Project Success

Based on the Children’s World Cup Soccer Rules

I am not a big sports fan. My husband is an avid fan of baseball and American football, but I usually go about my business despite the frequent exclamations of euphoria and despair that reverberate throughout the house during sporting events. But a recent visit with our grandsons raised my interest in one sport-soccer (football). Having recently played World Cup soccer with four grandsons aged 8-2, where the rules were emphatically if inconsistently enforced, I thought about how these children’s rules apply to projects. Given my lack of knowledge about the real World Cup rules, I don’t have the slightest inkling of whether these kids’ rules even come close to reality, but they seem to work. So, at the risk of overusing the myriad analogies relating to children’s play to projects, here are five Kids’ World Cup Rules for successful projects.

Rule #1: Define the goal and how to reach it. In our kids’ game the goal kept changing. That is, how a goal was achieved was fluid. If the ball was kicked inbounds but bounced off the pole it probably didn’t count as a goal. Sometimes a goal could be scored by kicking the ball under the table, sometimes by missing the table entirely. On our projects not only do we need to have clear, unchanging business and project objectives, but we need a clear plan for how to get there. If either the goal or the set of project management and business analysis processes vary too much, the players will be confused, frustrated, and ultimately unsuccessful.

Rule #2: Focusing too much on the goal at the expense of your opponent can get you a yellow card, which is like a strike in baseball. Three of them and you’re out, according to the Kids’ Rules. The grandsons loved marching around the field silently carrying a small yellow block when an infraction had occurred. In soccer we need to get the ball from our opponent in order to make a goal, but not by infringing on others. Many project managers focus on meeting the project objectives without paying enough attention to our “opponents,” those who are not supportive of the project. Perhaps the project goals and objectives are at odds with their own, perhaps they are uncomfortable with our project processes or they don’t like the sponsor or other stakeholders, perhaps the end result of the project means that they that they will have to learn new processes, no longer be experts, have to learn how to use new systems or products, or perhaps even lose their jobs. There are lots of reasons why some stakeholders may not want to support the project. However, it is vital to recognize the stakeholders who are our opponents and develop strategies to bring them on board.

Rule #3: The red card-means you’ve really messed up and you’re expelled from the game. Fortunately our grandsons were not cutthroat and red cards were not abundant. On projects expulsion can happen when trust has been broken. Sometimes we don’t even know that we’ve been expelled. But if we feel like a pariah, or if a lot of communication is going on behind our backs, or if our team seems less motivated, if subject matter experts (SMEs) start showing up late or missing meetings, we may have been expelled.

Rule #4: When we mess up unintentionally we might get a green card. A green card means a minor offense has been committed, but the play can proceed. In Kids’ Rules it means an unintentional offense. As grandparents and as project professionals we’re going to mess up, but if it’s unintentional, we will probably be forgiven. As a grandparent I usually got a green card for using my hands by mistake. However, when I used my hands several times in a row even though I didn’t mean to, patience wore thin, I was told “that’s not how you play the game,” and I was given a yellow card. On projects there will be times when we mess up, but as long as it’s unintentional and infrequent people will understand. But when we mess up the same way with the same stakeholders over and over, we are viewed as incompetent — a definite trust buster.

Rule #5: Don’t argue with the referee. You could end up with a red card. The referee is the referee. My grandsons were proud of Team USA who despite the bad call acted professionally and were good sports. On our projects the sponsor is the referee. We will probably disagree with our sponsor from time to time, but as we know the sponsor (referee) isn’t always right, but the sponsor is always the sponsor.

There are several other rules that apply, like what happens when we don’t have a referee (neutral facilitator) or when we don’t devote our entire attention to the game, but we’ll end here, wishing you fun with family and success with your projects.