I’ve been touching base with IT folks and analysts lately to get a feel for the projects people are working on these days, and the phrases that keep coming up are IT consolidation, modernization and innovation.
A senior network administrator with a national hospice care provider is working on a data center consolidation project. The C-levels are pretty keen on leveraging cloud services to outsource IT functions, but he’s not convinced it will happen.
“From what I’ve seen, the ROI for the cloud is not there yet,” he said. “When you factor in the actual costs of building it in-house vs. hosting, it’s a lot cheaper to do it in-house.”
So that is the back and forth under way at his company: IT consolidation — Do we do it ourselves, go with a cloud provider or take a hybrid approach?
The task ahead for IT is threefold, explains Burton Group analyst Joe Bugajski. IT needs to contract, modernize and innovate. SearchCIO.com senior writer Linda Tucci has written a series of stories with advice from CIOs on their approaches to IT innovation.
To get to the point in which IT can help the business innovate, it first has to solve an age-old problem: IT modernization, the subject of Bugajski’s talk at next week’s Burton Group Catalyst conference in San Diego.
And tied to modernization is consolidation. To get started, the CIO and IT will have to start talking to the business to figure out what technology, what applications and what projects are really needed — and what can go. That’s where the point of innovation can begin, he explains. IT consolidation will help you free up the needed capital that will allow you to start innovating and modernizing, vs. just maintaining.
The marching orders to modernize and contract need to come from the top — meaning the board, because C-levels can come and go, he said. So I’m wondering what your marching orders are? Are you being told to consolidate, modernize or innovate, or all of the above? Email me at email@example.com.
You share, collaborate and inform via email, phone, instant message and more — all because face-to-face time can be difficult to pull off in our increasingly busy schedules. And while some organizations have video conferencing capabilities to bring remote workers and office dwellers together, smaller organizations may not opt for the services.
However, a rise in mobile video devices, such as the iPhone4′s FaceTime and the Cisco Cius, could bring video anytime, anywhere. So how important will mobile video conferencing be to the enterprise?
On the one hand, mobile video conferencing will be a way to include traveling executives or remote workers in important meetings. On the other hand, these outward-bound employees may not always be in a private, quiet space that will allow them to fully participate.
The results of a 2009 CIMI Corp. survey of collaborative behavior showed that the number of mobile workers who believed that mobile video conferencing was helpful was less than 10%. The off-site workers did not feel they could actively participate in mobile video conferencing because of a lack of facilities, lack of network capacity to support connection and lack of privacy.
Another consideration is the potential for impromptu video conferences. Organizations with traditional conference rooms may have to plan their conferences weeks in advance. Conferences rooms with dedicated telepresence technology could book up quickly, but utilizing mobile technology on a tablet or similar device would allow users to pop into any room for a similar experience.
Plus, there is real value in being able to show someone explicitly how to do something and being able to read visual cues that could encourage communication and collaboration. Without these cues, it’s difficult to know when it’s appropriate to “jump in” on a voice conference.
The costs and benefits have to be weighed (and one may tip the scale in your organization), but remember: It’s not just about buying these devices — you have to consider changing work patterns and other business impacts.
In the past few weeks I’ve been writing about agile projects, Scrum vs. waterfall or using the two project approaches together, and a theme that keeps coming up when I talk to project managers is cutting the fat.
For a software development project to be agile, Alex Keenan, an ERP analyst and agile project team member with a large grocery chain, believes waste should be pinpointed as you plan and implement any project, and, with agile, continued to be identified with each project iteration.
He points to a Forrester Research chart that compares lean methodologies used in manufacturing and their counterparts for software development.
Sources of waste in manufacturing include: overproduction, waiting (time on hand), unnecessary transport, overprocessing or incorrect processing, excess inventory, unnecessary movement, defects and unused employee creativity.
The application development equivalents, according to Forrester Research, are: too many superfluous artifacts, broken builds, too many tool transitions, rigid architectures, analysis paralysis, late discovery of defects, rising downstream labor costs, polluted supply chain management streams and measure of effort and not results.
CIO Niel Nickolaisen also lays out how to translate lean methodologies to IT projects in a recent column.
From lean methodologies, I have learned about the seven forms of waste and how to map those to IT processes:
• Rework: How many times in IT do we ask for do-overs?
• Waiting: For example, we often have to wait for the input of a subject-matter expert before we can make a decision.
• Overprocessing: Research tells us that 64% of the software features and functions we develop are rarely, if ever, used.
• Excess inventory: A recent study found that about 40% of our software licenses are shelfware.
• Excess motion: How many of our status reporting mechanisms actually generate value rather than churn?
• Excess movement: Am I the only one whose projects get caught in multiple decision loops?
• Overproduction: How many of us buy licenses in large batches, rather than just in time?
These are a few takes on applying lean methodologies to IT projects and processes. What works for you? Email me at firstname.lastname@example.org.
Those looking to be certified in ITIL V2 Foundation have missed their chance: As of July 1, the V2 Foundation recertification is no longer offered, as the Office of Government Commerce slowly withdraws ITIL V2 in favor of ITIL V3. It’s out with the old, in with the new(ish) ITIL.
According to George Spalding, an executive vice president at IT management consulting firm Pink Elephant in Rolling Meadows, Ill., more than 300,000 individuals worldwide have taken IT Infrastructure Library (ITIL) exams since January 2009. While both V2 and V3 have been offered as of late, there were more people seeking V3 certification than V2. “It was time to get everyone up to speed on the same version, speaking the same language,” he said.
ITIL V3, introduced in 2007, emphasizes a more business-driven, top-down approach to IT management, an approach that was expected to gain more executive support. However, ITIL V3 gained momentum slowly. In an online ITIL adoption survey from Q3 2009 of organizations (mostly from North America) with 500 employees or more, the results showed that while ITIL V3 adoption was occurring, it was happening slowly and in pieces. At the time of the survey, only 4% of respondents indicated that they were implementing V3 from scratch.
Many organizations stuck with ITIL V2 Foundation for so long because they were comfortable with it. Plus, the timing was all off: Shortly after V3 was announced in 2007, we spiraled into a recession, so new initiatives were shelved. And before that, “many organizations were still maturing their ITIL V2 strategy,” Spalding said, “It can be hard to switch gears midproject and onto a new version.”
What does this really mean for users, that there won’t be another alternative for ITIL V2 Foundation certification? Will this affect your IT shop?
One of the 12 principles of agile projects is that agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely, according to the Agile Manifesto.
But project managers new to the agile approach are struggling with the concept of a project with seemingly no end.
I posed this question to several experts and was given a few straightforward answers: The project ends when you run out of funding. Another response was that it never stops. Like any other project, it is an ongoing process in which improvements and changes will constantly be made, even after it’s put into production.
Given its iterative nature, however, forecasting the end of agile projects isn’t so difficult.
Joseph Flahiff is a program manager with a national health insurance carrier. In charge of a $20 million HIPAA/EDI project that combines agile and waterfall approaches, he explains it this way:
You know just like any other project. If it’s managed with the waterfall approach, you’re probably given a scope of work: “These are the things we need you to do, and this is the goal we are trying to shoot for.” When you’re done with the scope of work, you are done with the project. What agile brings to [a project] is that you’re delivering all along, so you can see how close you are to actually being done.
Agile projects also allow you to fix problems as they arise, as opposed to a traditional software development approach in which most components are tested at the end. It’s a bottom-up development approach in which you are delivering working software all along, and you can show project sponsors how the team is burning — aka, the burndown rate — toward getting it done on schedule, done early or if you are running behind, he said.
“Then the leadership team or steering committee can actually take action and become involved, as opposed to looking at the [product] at the last minute and having a firefight,” Flahiff said.
Knowing when to end agile projects is but one quandary. Another project manager would like to know how to ensure that all the development iterations come together at the end. If you have any advice, email me at email@example.com.
Where does ITIL fit in with SMBs? It seems more organizations are following ITIL best practices in their overall IT operations and service delivery — creating some form of a service catalog, practicing change management strategies and focusing on service design — but not following ITIL frameworks full circle. Is the trend of ITIL a la carte a good thing?
For example, my colleague Christina Torode recently wrote a story about SMBs and service catalogs — and how many are using ITIL best practices to build a portal or a catalog that works for their specific organization, sometimes using SharePoint and workflow processes, without following ITIL to the letter.
Has ITIL matured to the point of being mainstream, as organizations learn how to pick and choose the ITIL best practices that best suit them? In other words, are they taking what they’ve learned about ITIL in the past and applying it in a more palatable way?
According to Evelyn Hubbert, a senior analyst at Forrester Research Inc., many of her clients have picked the critical pieces of ITIL they need to improve efficiency and effectiveness and adopted them as ITIL best practices. However, without accurate metrics measuring where IT was before the implementation and how ITIL has improved it, it’s harder to continue moving forward after the quick wins.
“[IT] cannot say where they are before they took off and don’t know where they have gotten to and cannot justify the benefits,” Hubbert wrote in an email. “Therefore, the effort is cut.”
Further, she said, ITIL adoption in terms of service delivery (a piece many organizations fail to add) needs to continue for organizations to stay competitive moving forward — especially as technologies continue to grow and change.
“I believe that ITIL will be part of most IT organizations … by 2012,” she said. “With clouds, virtual worlds, etc., the topics of service-level management, service portfolios [and] cost models will become much more critical.”
So the question remains: How much ITIL is enough?
To quote one respondent to my last blog post on whether agile projects should mix Scrum and waterfall: “I have been on projects within the U.S. government where they tried to do both when saying they were doing Scrum, and it was a disaster.”
Here is further explanation from the reader as to why Scrum and Waterfall is a bad combination:
The key issue in my opinion is that Scrum is a bottom-up communication process and that waterfall is a top-down communication process. In Scrum, the developers doing the work have their meeting, and that generates what is to be accomplished along with issues that have to be dealt with. This then rolls up to management, along with product owners, to make decisions about what will [work], what won’t, and help move obstacles out of the way. Waterfall is all about leadership telling everyone what they need accomplished, and meetings start at the top and come down. So issues in the trenches take longer to get back up, and it is more about low- and midlevel managers protecting themselves and driving the end workers to get things accomplished, then about figuring out what can be accomplished and passing that back up.
On the flip side, one project manager created what he calls the “Envelope Method,” which folds agile practices into waterfall, but he freely admits that it will shake up your organization. (Listen to a presentation that he gave on integrating agile into a Waterfall world during a recent Project Management Institute San Diego chapter event.)
Then there is the opinion that waterfall makes sense for certain kinds of projects, and Scrum others, as one reader explains:
Using the NASA cone of uncertainty, where uncertainty is high and learning must take place, a fail-fast approach is required, Scrum is put in for these parts. Where little or no uncertainty exists such as buying a completely set-up PC from Dell, waterfall can be used.
It all comes down to uncertainty due to:
- Rate of change.
- Complexity, both individual and overall.
- Interrelationships and dependencies.
- Lack of understanding how X provides value to [the] organization.
- [The] need to build individual and team competence to obtain individual and team confidence.
I will be following up with many of the people that emailed me. Some have traditionally used waterfall project methods but are trying to adopt/adapt some agile project practices into the requirements, development and testing phases.
I’ll be posting an update after these conversations to share what I learn about agile projects and the practice of mixing Scrum and waterfall.
I talked to a few CIOs recently who were using Scrum and Waterfall for agile project development. One was using a combination of the two to develop a portal and services for emergency room physicians.
But if you talk to some agile purists, they balk at the idea of using the two project development approaches together. At their basic premises, agile and Waterfall fight against one another: Waterfall deals with change by resisting it; while agile, and in particular Scrum, embraces change, according to Elena Mitelman, principal of agile consulting firm Smart Edge LLC.
To give a broader scope of Waterfall vs. agile approaches such as Scrum, here’s Mitelman’s take on both:
Used since mid-late 1990s.
Term formally coined in 2001 by Agile Manifesto.
Likens software development to lab research.
Still iterative, but iterations are unlike prior models.
Very light on documentation.
Manages risk between and within iterations.
Encourages risk-taking and exploration.
Keeps costs down by implementing only what’s required at this time, keeping things simple.
Chaotic, yet controlled.
Has been proven on many projects.
Not without implementation challenges.
Used since 1970s.
Assumes software development is similar to manufacturing and construction.
Sequentially flows from specifications through maintenance.
Deals with change by resisting it – cost of change goes up as project progresses.
Documentation-heavy process to prevent change.
In a perfect world, a simple and cost-efficient process.
But the world is not perfect…
And in the end, she is obviously a Scrum vs. Waterfall fan. Her reasons for evangelizing Scrum: It doesn’t prescribe to any specific engineering practices; it focuses on interactions between people; unlike Extreme Programming, or XP, it doesn’t require that you follow a number of set practices; and it is not specific to software development.
“[Scrum] can be used for any project, including launching a product, starting a company, etc.,” she said.
I’d like to hear from you if you are mixing and matching approaches, and how it’s working out for you, or if you think a Scrum and Waterfall combo leads to project failure. Email me at firstname.lastname@example.org.
A lot of projects fail. If business requirements aren’t clear or gathered effectively, or if the scope of the project is inaccurate, failure happens. But this past weekend, at New England GiveCamp (a Microsoft-sponsored volunteer weekend held at New England Research & Development Center — or NERD), it was refreshing to see some IT project success stories.
So, does it take a NERD to bring business and IT together effectively? Nonprofits without the time, budget or technical expertise necessary for application development projects or website overhauls rendezvoused with tech volunteers assigned to their projects, on a mission to make some big changes in a short amount of time.
It was the ultimate interface between IT and the business — and, as such, not without its challenges. In a lot of cases, those on both sides of the table initially struggled with the requirements portion of the IT projects. The business side was trying to describe what it wanted or needed, or even what was possible. The technical side was trying to translate these business requirements into something that makes sense and is totally workable in a 48-hour time frame.
Yes, some of the goals for IT project success were lofty — from brand-new website designs to customized desktop applications — but, amazingly, all were practically finished (I say practically because there were a few projects that still needed some fine-tuning or visual tweaks) by the end of the weekend.
How can this be?, I thought. It takes other companies, large and small, weeks, months, sometimes years to get an IT project completed. How can you get something up and running in just a few days?
The budget was limited (in most cases, nonexistent), the timeline was tight and there was a technical language barrier. However, there were no political barriers, approval processes, instances of organizational pushback or creative constraints. There were also a number of Scrum masters on hand — “an invaluable asset,” according to one volunteer, because they helped the groups set and follow tasks.
Interestingly, when all was said and done, there weren’t two sides of the table anymore. Working closely toward a common goal brought together each group, tech savvy or otherwise, and provided an excellent roadmap for IT project success.
It’s OK to fail when taking an agile approach to a business service or software development project, but if you fail, fail fast.
As one expert explained to me, if you don’t fail, you don’t really uncover the true nature of the problem trying to be resolved, or what works and doesn’t work.
“’Success is counted sweetest. By those who ne’er succeed,’ to quote Emily Dickinson,” said Ross Pettit, client principal at Chicago-based ThoughtWorks Inc. “You don’t want to be Wile E.Coyote, but you want to be in a situation in which you try and fail, because the more often you do that, the more you learn about the problem in front of you.”
He has seen too many agile projects fall apart because IT is afraid to fail. What ends up happening is failure on a larger scale; the project never crosses the finish line.
The iterative nature of the agile model allows for failures. Many agile projects are chunked out in weeks, so when something doesn’t work one week, you pick up the pieces, and apply what you learned to the next phase of the project.
Having project facilitators is critical to picking up the pieces quickly. This could be the CEO, the CIO, or a head of a department. Facilitators are the ones that the project team can turn to and say, “Here’s what we need access to, here’s the person we need to talk to, here’s the people we need to work on this problem.” “This allows stakeholders to make the resources available for what need to be done, immediately,” he said.
And if you are a stakeholder, don’t assume that you know what agile means. An agile model involves terms like velocity and iterations. A common word used by Pettit is story or an epic story to describe an agile project. All of these are common terms, but in the agile word they have a different meaning.
An epic story is the ultimate solution you want to achieve. So each release phase of the project tells part of the epic story, and is repeatedly compared with the theme of that story to make sure the project sticks to an agreed-upon plot.
“Just remember that very familiar terms are used in agile, so don’t understand them too quickly,” he said.
And don’t fall into the trap of viewing an agile model as one prescriptive approach that needs to be followed as if law. An agile approach is a living and breathing project that changes, otherwise it wouldn’t be called agile, points out Elena Mitelman, principal with agile consulting firm SmartEdge LLC.
She offers this other takeaway: