« April 2007 | Main | June 2007 »
May 16, 2007
Easy As Implementing a Package … Part 2
In Part 1 of an article series (see the posting here), I described the productivity characteristics of large IT package implementations, including enterprise resource planning (ERP) applications. I took on this subject in response to an article by my fellow Cutter colleague Steve Andriole (" Sourcing Today and Tomorrow," Cutter Consortium - 15 February 2007), who said that many CIOs and CTOs are often extremely frustrated by cost and schedule overruns in projects like this. In worst-case scenarios, some have even lost their jobs.
- There are several reasons why companies struggle greatly with project estimation when it comes to implementing packages, both large and small. Here are a few that are frequently cited:
- Implementing a software package means you're buying code (off-the-shelf) that someone else wrote and then attempting to make it work in your organization. Much of this work is about configuring and customizing the application, not writing your own code.
- More of the work can be about trying to figure out how the package works, what to use, how to then configure those parts (setting up rules engines and tables, for example), and deciding what parts NOT to use. There's a lot of thinking before any actual work gets done.
- Since you've typically had to buy the whole enchilada, it may take work to stub out parts that you decided not to use in order to set them aside.
- A centralized database is an essential aspect of this work; database conversions and migrations are frequently involved, as well as setting up tables and creating reports; little code work might be involved.
- Some organizations can't use a package strictly "as is." Rather than change how their organization works to suit the software, they feel they have to customize the software instead. That involves code work.
- Customizing software that someone else wrote is hard.
- After customization, there's still the task of retiring old applications, connecting the new system to legacy applications that are kept, and passing data across new interfaces that have to be written. Some are simple; some are complex ...
... and that very frequently involves -- guess what? -- writing code.
No wonder people's eyes glaze over at the prospect of implementing a package. How do you deal with something that involves code and, at the same time, doesn't involve code?
In the old days, frustrated by project overruns on new applications built from scratch, many believed that simply implementing COTS software would be the ticket out of project overrun hell. Just buy functionality, was the mantra. However, as packages got more complex and spanned more functional domains, even these projects became more difficult than anyone imagined.
But wait! Now that there's more and more industry data on projects like these, large and small, we're discovering how they are similar yet different than other software development projects. What does that mean to us? In a nutshell, it allows us to better estimate, plan, and manage this kind of work, upon which millions (or sometimes hundreds of millions) of dollars is often at stake. We've found that the productivity pattern of this work is often very similar to other complex IT undertakings, but SIZING these projects is what's different.
If you solve the sizing puzzle, it's possible to combine that knowledge with well-established productivity assumptions to predict more reliably the time and the work effort (person-months, hours, or days) that these projects could entail. The trick is sizing the work when some of it involves code (we're still talking about SOFTware, folks), while some of it doesn't, and then combining the two.
My friend and fellow Cutter colleague Ed Yourdon once said, "If you underestimate the size of your project, it doesn't matter which methodology you use, what tools you buy, or even what programmers you assign to a job." In other words, if you think a project is the equivalent of a little league ballpark and it turns out to be more like Yankee Stadium, your goose is cooked. Many package implementation projects start out looking small and then turn out huge, mostly because teams fail to size them well.
So here are a few examples of how others have sized package implementation projects successfully:
- You can count the number of high-level and then detailed business processes that are being automated. These are sometimes called "configuration items." When exploring how a package might suit these business processes, there are often cases where the functionality "fits," and in other cases, there are "gaps." You can also count these.
- Producing the desired functionality often involves creating items such as reports, tables, interfaces, database conversions, enhancements, and input forms. You can count these.
- Creating components such as interfaces often involves writing software. Simple interfaces might involve fewer (100 or so) lines of code (LOC), while complex interfaces often require more (1,000+).
- Components that don't involve code often require "programming actions" of some sort. While they're not about typing an instruction in a given programming language like C++, they are about producing an instruction nonetheless, like mouse clicks/drags for setting up tables, business rules, or invoking macros. Simple components require fewer of these "programming actions" or LOC equivalents, while complex components require more.
- There are often 10, 20, or so LOC equivalents on the smaller end of the scale, and maybe about 100 or so on the larger end. Since it's not really code but instructions, some teams count them as "logical instructions," "programming actions," or "implementation units."
Now comes the estimating part. Tallying up the size of all the work products can be done on a spreadsheet! You estimate the number of reports, interfaces, database conversions, enhancements, forms, and tables: 20 of these, 45 of those, and so on. Each of these components has a "currency conversion," such as the amount of code per interface or the number of programming actions/implementation units (LOC equivalents) for tables, reports, and the like. Then, adding it all up is simple, and when you look at the sum total, that's something that developers can handle. You've successfully estimated the size of your package implementation, in LOC equivalents.
Combining that with targeted productivity assumptions (low to high) based on how difficult the project might be can enable you to run a Monte Carlo simulation of how long the project should take and how much it might cost. If you have a reasonable handle on both the productivity and sizing assumptions, as well as the expected range, you can bet that you have a solid basis for a reasonable project estimate. As a result, there's far less risk of a disastrous overrun and/or slippage. That means CIOs can get to keep their high-paying jobs. If you successfully protect your CIO, that often is a good thing.
Posted by Mike at 03:29 PM | Comments (0)
May 04, 2007
Cutter Summit 2007 – Tom DeMarco’s Wrap-up
Well, a moment many of us have been waiting for has arrived. Tom’s wrap-up of the conference is a time when we get to go on a guided tour of “connecting the dots” as seen through Tom’s lens. Seeing Tom prepare his index cards at the front of the stage blows me away; the man is a quintessential pro at pulling it all together and saying it with a clarity and cohesiveness that allows us to make sense of it all - with a twist - in one amazing hour.
[This wrap up is giving me deja-vu from the years of amazing wrap-ups not only at the Cutter Summit Conferences, but during the days when the POPTech Conference was blessed to have Tom as it's former curator and host, with wrap-ups by Bob Metcalfe.]
What I love about this epilogue is that I get to hear things that I did not hear the first time (usually because I had been trying to concentrate on two things at once, because of simulcast blogging). But more importantly, it’s because of this: We all see the world through the lens of our own biases, opinions, and experiences. But when you listen to a recap of an even like the Summit, you get to see it (hear it) through the lens of one of the truly great technology thinkers of our time. And when Tom does his recap, I always hear new things that blow me away all over again.
[Karen Coburn was right when she asked people to reschedule their homeward flights or even walk home, if they had (mistakenly) planned to head to the airport before Tom’s wrap-up.]
Just a few short highlights of Tom’s highlights are:
IT is positioned to ride to its own rescue by opening up revenue opportunities from creating new things. [from Rob Austin]
IT has made globalization possible because it has laid the pipes and infrastructure around the world to move money across countries [at the speed of light].
Risk Management – and doing it right - is about wining BIG when you win, and losing SMALL when you lose. Rockwell Collins in Iowa is the poster child of that. The thousands of high-tech jobs in the middle of Iowa cornfields is the result of brilliant execution of that idea. (95% of the people who work at Rockwell come from their very own greater metropolitan (if you can call it that) region of Cedar Rapids.)
The Volkswagen case study allowed all of us to experience what it is like to argue a case at the Harvard Business School.
Paul Robinson’s leadership talk had a magical kernel – what sets apart great leaders is how they deal with “the error” [that is inherent in everything that we humans do]. Explicit gets all the attention but implicit is what matters (special thanks to the fantastic observations from Vince Kellen, CIO of DePaul University, who sat on the panel discussion.]
For the closing talk on Innovation – why DTE Energy as a focal point and not Apple, for example? Consider how challenging it is to be “innovative” at a place like a utility? And from Tom’s direct experience at having consulted there, how remarkable they are as a HEART-CENTERED company. Wow. This is one of those rare times that I have heard about a company being heart-centered.
Another tidbit – this is happening in (of all places) Detroit. 13,000 of the 15,000 best jobs in Detroit are at DTE. As an employer, they are single-handedly responsible for their home economy in much of the same way that Rockwell Collins – another great innovator – is to their home city of Cedar Rapids.
And what I thought was a brilliant close to Tom’s comments: It’s not really just companies that are innovative, it’s (and he looked at people right in the eye after a brief pause), it’s YOU. It's up to YOU.
And there it was: A deeply reflective and inspiring close to an incredible conference; one that we all will remember for a long time. I feel truly enriched by the experience.
Don’t miss the Cutter 2008 Summit… see you next year!
Posted by Mike at 04:44 PM | Comments (0)
May 03, 2007
Cutter Summit 2007 – Lynne Ellyn; Is Innovation Relevant to IT?
Lynne is VP and CIO at DTE Energy. She and I have enjoyed much of this conference sitting together in the back row, and she now takes the stage. Her IT operation is nearly 850 employees and is responsible for [get the stats from her slide].
In a nutshell, Lynne’s answer to this question is an unqualified yes, and she shows a timeline showing IT’s role in various industries over a 40 year period. Innovation has been there all along. Within DTE Energy, she cites examples like neural networks to optimize and forecast power demand, price analysis for electricity, and interactive voice recognition.
Given that innovation matters, DTE Energy gets innovative results by encouraging innovative behavior. It is recognized, celebrated, and rewarded. I’m impressed that this is explicitly managed and incentivized. She says that the culture “creates a state” where innovation is fostered within the company. It is for the clear intentions and purposes to increase revenue while reducing costs, improving service to its customers, manage better, and differentiate DTE from the competition.
I should note that Lynne stated earlier in the presentation that they chose an INSOURCING strategy to bring this about. This doesn’t mean that they spend more on IT; in fact, their benchmarks show lower IT spend for IT as a percentage of revenue. I’d be curious as to how they’d measure [output side] - the delivery of IT capability and other outcome/value metrics around the intentions and purposes in the previous paragraph.
What Lynne is also saying about sustaining momentum, is in the words of an executive coach who she worked with, “Give it a name.” As a result Lynne raises the visibility of the innovations at DTE – she itemizes them, attaches a value, and publicizes them. This amounts to an internal PR campaign. Keeping them a secret would diminish the momentum of their innovation culture. IT gets credit. I would imagine this fosters pride in their work. In so many organizations where problems always get the attention, morale suffers.
It’s interesting that Lynne says that another way to overcome stagnation is to rotate team members through different tasks. This focuses employees on new problems, encourages them to learn about new domains, and connecting with new co-workers. As an example, she was even asked to handle food service selection for cafeterias on the DTE campus. She wasn’t experienced at all in that, but the experience was valuable for her. Teams staying stuck in one class of work can lead to stagnation and a loss of innovative energy.
Barriers to innovation: statements like “We’ve always done it this way.” She says you should consider whether this ends the conversation, or starts the conversation.
A point that jumps off of one of Lynne’s slides: An innovative, collaborative culture leverages the strengths of a diverse talent pool. I think about Richard Florida’s expression of this idea on a macro-level when he describes the strength of the U.S. as having been a talent magnet for creative people from around the world to live and work. Lynne uses the example of the diverse skills of the Cutter Consortium as also being a model of innovation. It’s a talent pool that clients draw upon by gaining access to thought leadership by people at the top of their game in their respective areas of expertise. [This conference certainly has embodied that concept when I think about the speakers, the panelists, and finally, the members of the audience.]
Posted by Mike at 03:59 PM | Comments (0) | TrackBack
May 02, 2007
Cutter Summit 2007 – Paul Robertson; Art and Paradox of Leadership
Paul Robertson leads us into this subject; fascinating that for 35 years he was Founder and Leader of the world-acclaimed Medici Quartet. As we were gathering to start the session, he treated us to wonderful melodies on the solo violin - Bach I believe.
Along the lines of the theme “Pursuing Perfection,” he is guiding us through some music history. We are listening to him describe the master violinist Jascha Heifitz, now seeing some archival video of an actual performance. What an INNOVATIVE way of addressing the subject of leadership at a conference dedicated to the subject of innovation. It’s bold, interesting, entertaining, and engaging. (Writing this blog entry is a terrible distraction in some ways.)
Paul’s approach to this subject is by enabling us to see how the sheer charisma of Heifitz was in play while preparing to launch into a musical performance with an orchestra. His deliberateness, slowness, and engaging approach to setting the tone for the performance. Paul notes that Heifitz did not want to be “loved.” He wanted to be feared and respected.
Now we are seeing the contrast of leadership qualities chosen by Heifitz, with how Paul approached the creation of the Medici Quartet. We are hearing a dramatic, entertaining, funny, and insightful description of Paul’s world, framing the subject of leadership. The use of storytelling and the interspersing of musical notes his violin is brilliant. Brilliant! [I am so proud that he is a fellow Cutter consultant in our Innovation Practice. It is both humbling and inspiring to hear his command of the topic.]
[Question: How do you become a millionaire as a quartet player? You start out life as a billionaire. The crowd erupts in laughter! (They do not do this for the money…)]
Paul’s talk is deeply engaging and I’m finding it difficult to blog while listening, given the style and mapping of his ideas to this topic. I’m going to freehand write for a while, and compose my thoughts into an extension of this entry later.
Posted by Mike at 01:55 PM | Comments (0)
May 01, 2007
Cutter Summit 2007 - Volkswagen Case Study
This afternoon is a treat here at the Summit. Prof. Rogelio Oliva is leading a fantastic Harvard Business School (HBS) like case study for our group, using a real world situation at Volkswagen of America.
Rogelio was on the HBS faculty for Technology and Operations Management, and is now on the faculty at the Mays Business School. He has a PhD in Operations Management and System Dynamics from MIT. What a treat here! Rogelio is dynamic and fast-paced, and how he engages the audience makes everyone feel like they're sitting at HBS as fellow classmates. The case deals with real IT budgeting negotiations at VW/Audi, and the group is totally getting into it. Rob Austin co-wrote the case, and everyone in the room is having great fun debating the case, bringing a wealth of knowledge to the conversation.
It's a first for the Cutter Summit. Great fun. Lots of energy.
After a short break, we go into a panel discussion with Rogelio, Javier Gomez Diaz (CIO of Mexico's Grupo Bimbo and LatinAmerica CIO of the Year 2004 (Oracle Magazine) and Mexico CIO of the Year (InfoWeek), plus our own Mike Rosen (Cutter), and (surprise) a key player from Volkswagen from the case study, Warren Ritchie, IT Director.
Fantastic session, and Tom DeMarco is running the panel, which is another home run for the Summit. Wow.
Posted by Mike at 05:17 PM | Comments (0)
Cutter Summit 2007 – Rob Charette on Risk
Rob Charette is going into an area that most people might not think about when they think of risk (which usually evokes feelings of worry). The UPSIDE of risk. It will be interesting to hear how he frames this conversation. Most people when they think about risk fathom the downside.
Images that follow are photos of a hurricane, then a view above the clouds from the cockpit of an airplane. Rob is using a success case study of Rockwell Collins Avionics (disclosure: Rockwell had been a longtime client of QSM in the 1990s, using the SLIM suite of software estimation and measurement tools). Rockwell designs and builds commercial aircraft flight navigation and control systems for Boeing and Airbus.
Radar and the challenge of steering around thunderstorms is the metaphor right now, and he’s talking about how aircraft navigation and radar deals successfully with weather related risk for aircraft. We are moving into how aircraft displays deal with risk, and conveying that information to the pilot, reducing the three fundamental elements of pilot risk: Lack of Information, Lack of Control, and Lack of Time. These are designed to solve the problem of “pilot situational awareness.” The goal: “Don’t hurt people, don’t hurt the airplane, and provide passenger comfort."
Now Rob is blending the theme of innovation (and subsequent profit) with risk. I think he’s going to show how companies can creatively tackle risk in an innovative way. If they succeed, they will be at a competitive advantage and grow market share because they are positioned to deal with risks if they manifest, compared to companies that do not manage risk well and passively roll the dice on whether something bad will happen. (I think of Russian roulette.)
Rob is saying that you can be a great innovator, but it doesn’t matter if nobody buys what you’re innovating. He’s citing thinkers like Adam Smith, J.B. Bay, Ludwig von Mises, Joseph Schumpeter, Frank Knight, Peter Drucker, and Milton Friedman on various adages on innovation and entrepreneurship. It’s an interesting blending and connecting the ideas.
(Speaking of innovation, did you know that the iPod was originally released in 2001? It’s dominance of the marketplace came as a result of a series of small innovations in succession. If I’m correct, I would guess that the real explosion came when iTunes software was released for the Windows platform in 2003. At the time, over 1 million downloads occurred in the first 3.5 days. iTunes then sold over a billion songs in the three years that followed. Not bad - $1 billion in songs, in less than 3 years. Add the revenue from over 100 million iPods having been sold since its introduction. Who would have thought that iTunes would be the killer app to drive Apple’s iPod success?)
Now comes the panel discussion, with Lou Mazzuchelli (Cutter), Maria Pardee (BT Global), and Bart Perkins (Cutter) in addition to Rob Charette. Tom DeMarco is setting the stage. Tom says that Rob has laid down a wonderful metaphor that Rockwell Collins is a quintessential practitioner of risk management, and is an industry leader when it comes to innovation in the avionics sector (this is a good thing – remember: they build systems that fly airplanes.)
Lou starts out by saying that if you’re immersed in any kind of crisis within your company (your “hair is on fire”), then innovation is out the door. You have to deal with the fire first, before you can imagine doing any innovating. I am mindful of a corporate equivalent to Abraham Maslow’s Hierarchy of Needs - that few people self-actualize (innovate their lives) if they’re struggling to meet basic needs like food, water, and air.)
[My sense is that companies are continuously in some state of panic fire drill in this time-driven Internet-speed economy.]
Maria Pardee describes the challenges that BT faced on innovation and the risk for the company, during a time of a shrinking market. The transformation of the company occurred by turning it into a consumer oriented brand, in the face of the risk of them going out of business. This is an interesting linking of the topic of risk with innovation. She is describing how the company opened up its network to create new technologies, using open-source strategies and other execution ideas.
I am struck that as she talks about BT protecting the relationship of trust with its customers, that we’re talking about several ways of using the word “risk.” Risk of security of their telecom network, risk re: the relationship with its customers, security risks with regard to opening up it’s network to innovators who they needed to develop solutions, and the like.
I guess you can talk about risk when it comes to taking a risk on - ANYTHING. In that way, it is a universal topic. You can take risks and risk bad things happening, or you can take risks to avoid the risk of bad things happening. You can innovate to try and avoid negative consequences, or you can push the envelop and engage in risky behavior, where bad things might happen if you do it recklessly.
Take your pick on how you want to talk about this. If I were a panelist, how I’d start a dialog on this might be a function of my most recent experiences, and it could go anywhere, which can be good since the topic offers such flexibility. However, because of this, the panel might find it tricky to find convergence. It promises to be a pretty heterogeneous conversation.
Rob is launching into an interesting posit - to innovate you have to change the staus quo. Changing the staus quo is HARD; it feels very risky to make a strategic change, and do something different. In many cultures, it gets quashed which is what Lou is saying, and he goes back to the Apple story. Apple was brought back from the brink, and it took these risks during a time when it looked like the train was going off a bridge. Change usually doesn't happen when things are comfy cozy; they usually happen when things are at the brink.
Fear is a great motivator. I am conscious of the notion that people and companies are often motivated in either one of two ways: one - chasing the angels, or two (more commonly), running from the demons. My sense is that when you're operating out of fear, fight or flight responses are typically in play. In this state of mind, people can be incredibly focused, but at the same time, judgment is often compromised. (See my post on "Worrying About the Wrong Things")
Posted by Mike at 12:32 PM | Comments (0) | TrackBack