Blog-Bout: “Risk” versus “Monopoly”
Jim Harris in Blogs, Data Quality, Debates tagged Blog-Bout, Business-IT Collaboration, Phil Simon, Philosophy Tuesday, October 13, 2009 at 9:00AM A “blog-bout” is a good-natured debate between two bloggers. This blog-bout is between Jim Harris and Phil Simon, where they debate which board game is the better metaphor for an Information Technology (IT) project: “Risk” or “Monopoly.”
Why “Risk” is a better metaphor for an IT Project
By Jim Harris
IT projects and “Risk” have a great deal in common. I thought long and hard about this while screaming obscenities and watching professional sports on television, the source of all of my great thinking. I came up with five world dominating reasons.
1. Both things start with the players marking their territory. In Risk, the game begins with the players placing their “armies” on the territories they will initially occupy. On IT projects, the different groups within the organization will initially claim their turf.
Please note that the term “Information Technology” is being used in a general sense to describe a project (e.g. Data Quality, Master Data Management, etc.) and should not be confused with the IT group within an organization. At a very high level, the Business and IT are the internal groups representing the business and technical stakeholders on a project.
The Business usually owns the data and understands its meaning and use in the day-to-day operation of the enterprise. IT usually owns the hardware and software infrastructure of the enterprise's technical architecture.
Both groups can claim they are only responsible for what they own, resist collaborating with the “other side” and therefore create organizational barriers as fiercely defended as the continental borders of Europe and Asia in Risk.
2. In both, there are many competing strategies. In Risk, the official rules of the game include some basic strategies and over the years many players have developed their own fool-proof plans to guarantee victory. Some strategies advocate focusing on controlling entire continents, while others advise fortifying your borders by invading and occupying neighboring territories. And my blog-bout competitor Phil Simon half-jokingly claims that the key to winning Risk is securing the island nation of Madagascar.
On IT projects, you often hear a lot of buzzwords and strategies bandied about, such as Lean, Agile, Six Sigma, and Kaizen, to name but a few. Please understand – I am an advocate for methodology and best practices, and there are certainly many excellent frameworks out there, including the paradigms I just mentioned.
However, a general problem that I have with most frameworks is their tendency to adopt a one-size-fits-all strategy, which I believe is an approach that is doomed to fail. Any implemented framework must be customized to adapt to an organization’s unique culture.
In part, this is necessary because implementing changes of any kind will be met with initial resistance, but an attempt at forcing a one-size-fits-all approach almost sends a message to the organization that everything they are currently doing is wrong, which will of course only increase the resistance to change.
Starting with a framework simply provides a reference of best practices and recommended options of what has worked on successful IT projects. The framework should be reviewed in order to determine what can be learned from it and to select what will work in the current environment and what simply won't.
3. Pyrrhic victories are common during both endeavors. In Risk, sacrificing everything to win a single battle or to defend your favorite territory can ultimately lead you to lose the war. Political fiefdoms can undermine what could otherwise have been a successful IT project. Do not underestimate the unique challenges of your corporate culture.
Obviously, business, technical and data issues will all come up from time to time, and there will likely be disagreements regarding how these issues should be prioritized. Some issues will likely affect certain stakeholders more than others.
Keeping data and technology aligned with business processes requires getting people aligned and free to communicate their concerns. Coordinating discussions with all of the stakeholders and maintaining open communication can prevent a Pyrrhic victory for one stakeholder causing the overall project to fail.
4. Alliances are the key to true victory. In Risk, it is common for players to form alliances by combining their resources and coordinating their efforts in order to defend their shared borders or to eliminate a common enemy.
On IT projects, knowledge about data, business processes and supporting technology are spread throughout the organization. Neither the Business nor IT alone has all of the necessary information required to achieve success.
Successful projects are driven by an executive management mandate for the Business and IT to forge an alliance of ongoing and iterative collaboration throughout the entire project.
5. The outcomes of both are too often left to chance. IT projects are complex, time-consuming, and expensive enterprise initiatives. Success requires people taking on the challenge united by collaboration, guided by an effective methodology, and implementing a solution using powerful technology.
But the complexity of an IT project can sometimes work against your best intentions. It is easy to get pulled into the mechanics of documenting the business requirements and functional specifications, drafting the project plan and then charging ahead on the common mantra: “We planned the work, now we work the plan.”
Once an IT project achieves some momentum, it can take on a life of its own and the focus becomes more and more about making progress against the tasks in the project plan, and less and less on the project's actual business goals. Typically, this leads to another all too common mantra: “Code it, test it, implement it into production, and then declare victory.”
In Risk, the outcomes are literally determined by a roll of the dice. If you allow your IT project to lose sight of its business goals, then you treat it like a game of chance. And to paraphrase Albert Einstein:
“Do not play dice with IT Projects.”
Why “Monopoly” is a better metaphor for an IT Project
By Phil Simon
IT projects and “Monopoly” have a great deal in common. I thought long and hard about this at the gym, the source of all of my great thinking. I came up with six really smashing reasons.
1. Both things take much longer than originally expected. IT projects typically take much longer than expected for a wide variety of reasons. Rare is the project that finishes on time (with expected functionality delivered).
The same holds true for Monopoly. Remember when you were a kid and you wanted to play a quick game? Now, I consider the term “a quick game of Monopoly” to be the very definition of an oxymoron. You’d better block off about four to six hours for a proper game. Unforeseen complexities will doubtlessly delay even the best intentions.
2. During both endeavors, screaming matches typically erupt. Many projects become tense. I remember one in which two participants nearly came to blows. Most projects have key players engage in very heated debates over strategic vision and execution.
With Monopoly, especially after the properties are divvied up, players scream and yell over what constitutes a “fair” deal. “What do you mean Boardwalk for Ventnor Avenue and Pennsylvania Railroad isn’t reasonable? IT’S COMPLETELY FAIR!” Debates like this are the rule, not the exception.
3. While the basic rules may be the same, different people play by different rules. The vast majority of projects on which I have worked have had the usual suspects: steering committees, executive sponsors, PMOs, different stages of testing, and ultimately system activation. However, different organizations often try to do things in vastly different ways. For example, on two similar projects in different organizations, you are likely to find differences with respect to:
- the number of internal and external folks assigned to a project
- the project’s timeline and budget
- project objectives
By the same token, people play Monopoly in somewhat different ways. Many don’t know about the auction rule. Others replenish Free Parking with a new $500 bill after someone lands on it. Also, many people disregard altogether the property assessment card while sticklers like me assess penalties when that vaunted red card appears.
4. Personal relationships can largely determine the outcome in both. Negotiation is key on IT projects. Clients negotiate rates, prices, and responsibilities with consulting vendors and/or software vendors.
In Monopoly, personal rivalries play a big part in who makes a deal with whom. Often players chime in (uninvited, of course) with their opinions on potential deals, without a doubt to affect the outcome.
5. Little things really matter, especially at the end. Towards the end of an IT project, snakes in the woodwork often come out to bite people when they least expect it. A tightly staffed or planned project may not be able to withstand a relatively minor problem, especially if the go-live date is non-negotiable.
In Monopoly, the same holds true. Laugh all you want when your opponent builds hotels on Mediterranean Avenue and Baltic Avenue, but at the end of the game those $250 and $450 charges can really hurt, especially when you’re low on cash.
6. Many times, each does not end; it is merely abandoned. A good percentage of projects have their plugs pulled prior to completion. A CIO may become tired with an interminable project and decide to simply end it before costs skyrocket even further.
I’d say that about half of the Monopoly games that I’ve played in the last fifteen years have also been called by “executive decision.” The writing is on the board, as 1 a.m. rolls around and only two players remain. Often player X simply cedes the game to player Y.
You are the Referee
All bouts require a referee. Blog-bouts are refereed by the readers. Therefore, please cast your vote in the poll and also weigh in on this debate by sharing your thoughts by posting a comment below. Since a blog-bout is co-posted, your comments will be copied (with full attribution) into the comments section of both of the blogs co-hosting this blog-bout.
About Jim Harris
Jim Harris is the Blogger-in-Chief at Obsessive-Compulsive Data Quality (OCDQ), which is an independent blog offering a vendor-neutral perspective on data quality. Jim is also an independent consultant, speaker, writer and blogger with over 15 years of professional services and application development experience in data quality (DQ), data integration, data warehousing (DW), business intelligence (BI), customer data integration (CDI), and master data management (MDM). Jim is also a contributing writer to Data Quality Pro, the leading online magazine and community resource dedicated to data quality professionals.
About Phil Simon
Phil Simon is the author of the acclaimed book Why New Systems Fail: Theory and Practice Collide and the highly anticipated upcoming book The Next Wave of Technologies: Opportunities from Chaos. Phil is also an independent systems consultant and a dynamic public speaker for hire focusing on how organizations use technology. Phil also writes for a number of technology media outlets.
Reader Comments (13)
First of all, both of you should get a life :)
I felt that both of your comparisons were fair and I can relate to the points you are making.
I tend to agree and nod more with Phil's comparison though.
Both comparisons kind of fail in matching up IT Project Goal vs. Goal of the game.
Goal of IT Projects is to achieve the outcome which benefits the business (Group or all teams).
In the case of Risk or Monopoly, the goal is to benefit individual players.
My 2 cents...
Vish Agashe
Vish,
First of all, thanks for your comment. Your feedback is always greatly appreciated.
Secondly, I can't believe that one of my readers is voting for Phil :)
Seriously though, you make an excellent point (as always) - I completely agree with you that the goal of any IT Project must be to benefit the business (i.e. the entire organization).
Thanks and Best Regards...
Jim
Mark it, Dude. :)
I agree that there are some parallels between Monopoly and data quality as I wrote in a blog post here.
But guys, the obvious metaphor of choice here is the Game of Life.
In Life, you can collect a big payday every time you implement. There will be obstacles in your path, but you avoid them if you have insurance. Pay attention to the stock market and only gamble when the time is right.
Anyway, I'm glad to see we're having fun.
Hey Jim, you got a job for me, I can play Risk ...
Seriously though, I voted for you, perhaps just because I have met you. However, political forces within the organization play such a massive role in any business change initiative, unless you successfully manage your way through the political minefield, make alliances, and risk sacrificing all along the way, you risk total defeat. GO JIM!
P.S. - To be honest, I voted for you and that you should get a life, but that was just to mess up your data :)
While there are compelling arguments for both RISK and MONOPOLY, the discussion misses the opportunity to view IT projects not as a game with opposing teams but as a collaborative effort by one enterprise to meet a need in the market at a competitive and profitable price.
Since I saw this item through an IBM group discussion, it seems appropriate to mention an exercise IBM once used in Senior Management training. The game was set up as a contest between teams with the opportunity to “change the rules” if warranted.
We never changed the rules to take advantage of point 4 in both Jim’s and Phil’s blog-bout: the ability for individuals to overcome rivalries and establish alliances for the team’s success.
Once we saw the advantage of viewing any project as a team success, we “changed the rules” throughout the rest of the week’s training. What fun that was.
John Crosby (www.jadtech.com)
John,
Thanks very much for sharing your perspective.
I definitely agree with you - we need to view any project as a team success achieved by a collaborative effort.
Best Regards...
Jim
Great responses, all.
Steve – Hey. Game of Life...I like that.
Jim – I’m glad that we can spur a quasi-serious debate.
Tip all the Monopoly pieces in a pile, add to it all the pieces from Risk, throw in some Chess pieces for good measure and stir well. Now that's an IT Project. You'd better use 2 Monopoly sets as there won't be enough money in just one.
For that reason, I vote Monopoly :-)
P.S. Add Stratego: where there's always key pieces hidden from view.
P.P.S. I'm not really that cynical ;-)
Whose turn is it?
Wow - that now makes two of my readers who have voted for Phil Simon!
No wonder I am losing this blog-bout!
It's a good thing that I am not a sore loser ;-)
Guys,
The entire blog-bout shows the problem, overcomplication :-)
We trundle along a planned path in a basic ground state with unexpected obstacles thrown in our way and the occasional good thing happening...
Isn't this 'Snakes and Ladders' ?
G
I have to vote for Monopoly for point 3. In Monopoly you can bend the rules to survive:
"I'll pay you next time I pass go" or "Instead of paying you $500 I'll give you a Get Out of Jail Free Card and a freebie next time you land on me", or the rules that let everyone screw the bank - like letting people sell properties back to the bank at face value even if they are in mortgage!
Keeps the game going for longer. Just like bending the rules lets IT project managers juggle funding and secure resources and shift work in and out of scope to meet deadlines.
Wow, that's totally hilarious.
I must say I identify with the Risk analogy more. Maybe that's just me liking Risk better as a game. I was trying to find something about Risk vs. Monopoly for a paper, and this came up...really crazy, but interesting...
And you both should get a life - it would be a good idea ;)