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 …
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 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, and blogs on his Virtual Soap Box.