How Can Lean Software Enable You To Better Serve The Business? #BTF09

John Rymer and Dave West presented a breakout session in the application development track on how Lean software development practices can be applied in your business. This obviously had a big focus on Agile, and how it can be used within large organizations. Unlike what some people think, Agile isn’t cowboy coding: it is quite disciplined, but it is optimized for delivering the right thing (from a business standpoint) in the minimal time. It’s all based on four principles: deliver the right product, provide hard value, simplify the platform, and allow efficient evolution. An optimal strategy depends on all four of those elements, but Agile projects may deliver on two or three of them, proving the value of Agile before a full Agile strategy is in use.

In order to apply these principles across your entire application development portfolio, you need a strategy that addresses these elements, and provides some way to measure the impact of such a strategy. Delivering the right product requires a focus on people and talent, and the industrial concepts of mass customization rather than mass production; providing hard value requires linking your development process to value streams with their focus on investment return; simplifying the platform requires a focus on tools and technology; and allowing efficient evolution requires optimizing work processes both within development teams and across the organization. I especially liked their chart comparing today’s practices in tools and technologies against Lean practices:

Today’s practices

Lean practices

Install for today and tomorrow Install for today, architect for tomorrow
Configure a general UI for many users Design for people in their work roles
Adopt integrated suites Adopt narrow-purpose modules and services
No component substitution is allowed Component substitution is allowed
Architectural evolution is slow by design Architectural evolution is constant by design

There are ways to bring Agile into an organization, even when budgets are flat and there is the perception that legacy systems just can’t be replaced without yet another huge project expense. Likely, your developers are already practicing some Agile methods already, and you could easily gain permission to prove these out in non-critical systems development.

Good session, with a high-speed tag team between Rymer and West. Unfortunately, the logistics aren’t quite as good as the general sessions: too-small meeting rooms requiring elevator access from the main conference area, no tables and no wifi coverage (at least in the room that I was in at this time).

Waterfall contracts and iterative development don’t mix #BTF09

The post title is the best quote from Tom Higgins, CIO of the Territory Insurance Office in Australia, who came all the way from Darwin to speak at both the Gartner and Forrester conferences this week. I had a chance for a chat at the airport with him while waiting for our flight from Orlando to Chicago (and introduced him to the wonder that is the Chicago transit system), and caught his Appian-sponsored lunch presentation today.

TIO is a government-backed insurance operation that covers risks that most insurance companies won’t take on, including workers’ compensation, cyclone damage and other personal and P&C policies. They were looking to reduce their operational costs by making their claims operation more efficient, but also reducing their claims costs by reducing the length of disability claims, which can often be done through proper case management during the period of a claim. Originally the business was set on a COTS (commercial off-the-shelf) claims management system, but when they compared that with BPM, they realized that it met their requirements much better than the COTS systems available due to the ease of use and flexibility. They short-listed three vendors and did a three-day proof of concept with each; that managed to knock one vendor completely out of the running due to the complexity of the implementation, in spite of them being a large and well-respected vendor in the space (no, he didn’t say who; yes, he told me over a beer; and no, I won’t tell you).

For a short presentation, he spent quite a bit of time talking about the contract – including the “waterfall contracts and iterative development don’t mix” line – and I have to agree that this is an incredibly critical part of any BPM project, and very often is handled extremely poorly. The contract needs to focus on risk management, and you can’t let your lawyers force you into a fixed-price contract that has pre-defined waterfall-type milestones in it if you don’t know exactly what you want; in my experience, no BPM project has ever started with the business knowing exactly what they want ahead of time, and I don’t imagine that many do, so don’t mistake a contract for a project plan. If you plan on doing iterative or Agile development, where the requirements are defined gradually as you go along, then a fixed-price contract just won’t work, and will be a higher risk even though many (misinformed) executives believe that fixed price is always lower risk. Going with a time and materials contract requires a much higher level of trust with the vendor, but it will end up as a much lower risk since there won’t be the constant stream of change requests that you typically see with a waterfall contract. Besides, if you can’t trust the vendor, why are you working with them?

TIO had a number of issues pop up during their implementation: the CEO was replaced just before the vendor was engaged, and the business sponsor was replaced in the middle of development; however, due to a strong sponsorship and governance team, they were able to weather these storms. In fact, he sees the strength of the governance team as a critical success factor, along with using your “A team” for implementation, finding a committed vendor and engaging the business early.

He had a really good point about making sure that your project managers is not a business subject matter expert and does use an appropriate project methodology such as Agile. The PM is supposed to be the coordinator and facilitator of the entire project, and not an SME that will dive down the rabbit hole of specific business issues and requirements at the first sign of trouble. I’m a strong believer that PMs should manage projects, not gather requirements, write code or most other activities since that distracts them from the project and increases the risk that it will run off the rails when no one is looking; it’s good to hear that at least one other person shares my opinion on this.

They used Agile project methodology and Spiral development methodology, with six-week code cycles. The team was fairly small: seven TIO team members, an internal business reference group (the SMEs, who eventually became the rollout leads), four Appian people onsite, four offshore Appian team members, and four part-time specialists. The project started with Appian as the technical lead, but that shifted through the first three project phases, and now TIO essentially works on its own with no assistance from Appian. They established a center of excellence to assist with taking this success on to other projects, and that seems to be working: the initial project cost them over $3M, and the next one – which is three times more complex – cost only one-third of that since BPM is now built into their enterprise infrastructure. And, at the end of the day, they’re seeing a 30% productivity increase in their initial implementations.

Their biggest challenges were the introduction of Agile and Spiral methodologies, the geographic dispersion of the team, and recruiting the right talent for their remote location; they used internal education both for the methodologies and to grow their own BPM specialists locally when they couldn’t recruit them.

There were several things that they did that he feels contributed to their success, such as daily headline meetings, engagement with the business, fostering team spirit, and highlighting and addressing the riskier requirements early so that they can be tried out by the business and tuned as required. He also felt that Agile was a huge contributor, since there were no more 300-page requirements documents that were either not read or not understood by the business, but signed off regardless. He finished with a few strategic lessons learned: begin with the end in mind, including planning how this will become part of the infrastructure; and pick a big project in order to ensure commitment and executive engagement.

Embrace Lean thinking to enable innovation #BTF09

The morning finished with a panel moderated by Dave West of Forrester, and including Kevin Haynes of Dell and Dave Smoley of Flextronics. West started out talking about the inertia within IT: more than 60% of IT is spent just keeping the lights on, legacy systems inhibit change and vendors are slow to change. There is, however, a wave of change coming, with Agile adoption at 36% and rising, 80% of developers using open source and new software development up by 9%.

Smoley told about their experiences at Flextronics, where Lean has spilled over from manufacturing to IT, allowing them to reduce their IT costs to less than 1% of revenue. They were able to reduce their IT costs by 36%, all while performing some major projects such as a new supply chain management system, a global HR system, a WAN refresh, a data center refresh and implementing a global service desk. He credits Lean with being able to determine what technology is important and what is unimportant to the business, allowing them to cut or rework the areas of waste. Their strategy includes a “just enough” mentality, putting the customer first, trying out hardware and software before they buy it, maximizing asset utilization, consolidating wherever possible, and enabling global collaboration. Projects are prioritized by ROI, and business alignment is done at multiple levels. They avoid single source, aren’t afraid to renegotiate maintenance contracts, and use open source and open standards where possible. They also bite the bullet and actually throw stuff out if it no longer is the best thing for them, which often requires putting people’s egos aside if they were involved in the original development or acquisition of a system that is being decommissioned.

Haynes related what they’ve done at Dell, which has been focused on keeping the lights on rather than innovation, but maintaining the important operations and customer service levels while spending less. Their strategy is focused on decreasing variability, focusing on projects that reduce costs while driving service excellence, and consolidation through virtualization and techniques such as reducing to three standard desktop images. All of this is not just about exciting new innovation, either: it’s just as necessary to focus on better ways to handle the steady-state maintenance projects as well, and automate them where possible to free up resources.

The discussion ranged across both strategic and operational aspects of how Lean is helping both organizations to reduce their IT costs, and way too much information for me to capture, especially since West seems to have ADD when it comes to handing the remote control to advance slides :)  There were some good takeaways about Lean, such as transparent reporting on value and waste, establishing the right team culture around a problem-solving approach, creating structure around value chains, and frequent delivery to allow for constant fine-tuning of the business value.

The power of Lean IT #BTF09

John Swainson, CEO of CA, gave a presentation on how Lean can help companies built long-term competitive advantage during tough economic times in industries as diverse as manufacturing, healthcare, retail and IT, and how Lean IT – or what he referred to as the industrialization of IT – can deliver greater value at lower cost. As he pointed out, it’s about time that we applied some discipline to IT, and we can learn from how Lean helped other types of organizations to create just-in-time IT that deploys the right solutions at the right time.

Lean IT is about a “sense and respond” philosophy that has IT paying attention to what’s happening in the business and manage variable volumes, prioritize and create new business services, and ensure ongoing quality levels.

CA commissioned a study on waste, and found that 96% of IT executives agree that there is significant waste in their organization, primarily due to inefficient processes, duplication of effort, redundant applications, and underutilized assets; Swainson sees that the keys to resolving these issues is to analyze, automate, integrate and optimize (respectively).

He was then joined on stage by John Parkinson, CTO of TransUnion. As a credit rating/tracking service that tracks individual consumer credit ratings around the world, IT is absolutely central and critical to their operations, not just a support function. As the recession approached in 2007, however, they had to consider how to grow new sources of revenue and increase operating margins in order to decrease their dependency on the failing consumer credit market. Lean was part of their strategy, helping them to pinpoint the wasted effort and other waste, and allowing them to optimize their operations. With their corporate culture, they needed this to have this be more of a grassroots initiative that made sense to people: adopting Lean since it helped them to do their job better, not because of a corporate mandate. There is, however, monitoring and measurement in place, and performance and compensation are tied to improvements: the ultimate incentive. Their idea is to instill these Lean ideas into their culture, so that these good habits learned in tough times would serve them well when times improve.

Parkinson pointed out specifically that Lean sets you up for taking advantage of cloud computing, and Swainson took over to talk about the opportunities and challenge of working in the cloud. It’s pretty hard to embrace Lean without at least taking a look at using the cloud, where you can provision the right resources at the right time, rather than having a lot of excess capacity sitting around in your data center. Consider non-production environments such as test labs, for example: being able to create test environments as required – either through internal virtualization (which I don’t really consider to be cloud) or in an environment such as Amazon EC2 – rather than having them pre-installed and ready long before required, and sized for peak rather than actual load. Considering that test environments can be 2/3 or more of the server footprint, this is huge.

Mike Gilpin joined them for a discussion, which briefly continued on the topic of using virtualized or cloud test environments, but also covered the issues of how well contract IT employees can adapt to Lean cultures (if they don’t, then find someone else), using other techniques such as Six Sigma together with Lean (they’re all tools focused on process optimization, pick and choose what works for you), and the security challenges of using cloud infrastructure.

George Colony on the CEO’s brain #BTF09

We had a brief address from George Colony, CEO of Forrester, on changing from IT to BT, with one key message: if your CEO doesn’t understand what you’re talking about, then you’re probably not using “BT speak”.

The CEO is focused on two things: higher profits, and revenue growth, and you need to translate your projects and technology strategy into those terms, or risk being marginalized within the organization.

A brief 10-minute address, but a good message.

Lean and the CIO #BTF09

Tom Hughes, currently with CSC but formerly the CIO of the US Social Security Administration, spoke to us about Lean and the CIO. The imperative here is driven by surveys that show that (to paraphrase) business thinks that IT is important, but that they’re doing a crappy job. He believes that CIOs need to break out of the technology pack and focus on business outcomes (e.g., market share) rather than outputs (e.g., number of workstations): exactly the same message as Connie Moore gave us in the opening keynote. CIOs needs to be valid members of the executive team, reporting to the board rather than the COO, HR, general counsel or any of a number of other non-effective reporting structures.

He believes that the CIO of the future must:

  • Be a strategic thinker, not an IT techie
  • Be at the table of chief executives
  • Partner in agency or business transformation
  • Have broad experience

The CIOs focus needs to be on four things: strategy, budget, architecture and security. Delivery and maintenance, on the other hand, are operational issues, and should be handled below the CIO level, even directly in the business units by promoting cross-functional ownership. The CIO needs to be forward-thinking and set strategy for new technologies such as cloud computing and unified communications, but doesn’t need to be responsible for delivering all of it: for things that the business can handle on their own, such as business process analysis, let the business take the lead, even if it means acquiring and deploying some form of technology on their own.

He concluded with the statements that the CIO needs to work with the CEO and develop a collaborative operational model, be at the table with other senior executives, and get other executives to take accountability for how technology impacts their business area. The CIO needs to be seen by the CEO as a partner in business transformation, not the guy fixing his Blackberry.

Questions from the audience included how to transition the current technology-focused IT teams to have more of a business focus: Hughes’s response is that some of them will never change, and won’t make the cut; others can benefit by being seconded to the business for a while.

On a side note, I like the format of the keynotes: Mike Gilpin pops up on stage at the end of each one, he and the speaker move to a couple of comfy chairs at center stage, and he asks some questions to continue the conversation. Questions from the audience are collected on cards and vetted by Forrester analysts, who then distill them into a few key questions to ask.

There’s still a bit of confusion over the Twitter hashtag: the website says #BTF09, then Gilpin announced in the opening address that it is #FBTF09, but then @forrester DM’ed me that it is actually #BTF09 and that Gilpin will correct this, although that hasn’t happened yet.

Why Lean is the new business technology imperative #BTF09

I’ve moved from the Gartner BPM summit in Orlando to Forrester’s Business Technology Forum in Chicago, where the focus is on Lean as the new business imperative: how to use Lean concepts and methods to address the overly complex things in our business environment.

Mike Gilpin opened the conference with a short address on how our businesses and systems got to be so bloated that lean has become such an imperative, then Connie Moore took over for the keynote. From the keynote’s description on the event agenda site:

Lean is not a new business concept — but it is enduring. By embracing Lean years ago, Toyota reached No. 1, while rivals GM and Chrysler collapsed into wards of the state. In its broadest sense, Lean seeks to better satisfy customer needs, improve process and information flows, support continuous improvement, and reduce waste. Today’s recession is a clarion call for businesses and government to reexamine and reapply Lean thinking across people, processes, and technology. When maintenance eats 80% to 90% of IT budgets, it’s beyond time to examine Lean approaches — like process frameworks, cloud computing, SaaS, Agile methodologies, open source, or other fresh ideas. And when the sheer complexity of technology overwhelms information workers, it’s time to simplify and understand what workers really need to get their jobs done. And by focusing on Lean now, your organization will be positioned to power out of the recession and move quickly into the next new era of IT: business technology — where business is technology and technology is business.

She started with discussions about how Lean started in manufacturing, and you can see the obvious parallels in information technology. In Lean manufacturing, the focus is on eliminating waste, and everyone owns quality and problems are fixed at the source. Lean software isn’t a completely new idea either, but Forrester is pushing that further to change “information technology” to “business technology”.

Lean is not just operational, however, it’s also strategic, with a focus on understanding value. However, it’s usually easier to get started on it at the operational level, where it’s focused on eliminating waste through improving quality, eliminating non-productive time, and other factors. Lean can be counterintuitive, especially if you’ve been indoctrinated with an assembly line mentality: it can be much more efficient, for example, for individuals or small teams to complete an entire complex task from start to finish, rather than have each person or team perform only a single step in that task.

Moving on to the concepts of Lean software, she started with the results of a recent Forrester survey that showed that 92% think that enterprise software has an excessive cost of ownership (although personally, I’m not sure why they bothered to take a survey on something so incredibly obvious 🙂 ), and discussed some of the alternatives: SaaS such as Google Apps, open source or free software and other lighter weight tools that can be deployed at much less cost, both in licensing costs and internal resource usage. Like Goldilocks, we need to all start buying what’s just right: not too much or too little, in spite of all those licenses that the vendor wants to unload at a discount before quarter-end.

Looking at the third part of their trifecta, there’s a need to change IT to BT (business technology). That’s mostly about governance – who has responsibility for the technology that is deployed – and turning technology back into a tool that services the business rather than some separate entity off doing technology for its own sake. What this looks like in practice is that the CIO is most likely now focused on business process improvement, with success being measured in business terms (like customer retention) rather than IT terms (like completing that ERP upgrade on time, not that that ever happens). Stop leading with technology solutions, and focus on value, flexibility and eliminating waste. You can’t do this just by having a mandate for business-IT alignment: you need to actually fuse business and IT, and radically change behaviors and reporting structures. We’re stuck in a lot of old models, both in terms of business processes and organizational models, and these are unsustainable practices in the new world order.

There were some good questions from the audience on how this works in practice: whether IT can be Lean even if this isn’t practiced elsewhere in the organization (yes, but with less of an effect), what this means for IT staff (they need to become much more business focused, or even move to business areas), and how to apply Lean in a highly regulated environment (don’t consider required compliance as waste, but consider how to have less assembly-line business processes and look for waste within automated parts of processes).

Forrester Day 2: Colin Teubner

The last session of the last day, and a significant portion of the audience (especially those headed east) have bailed out but there’s still a few of us hanging around to hear Colin Teubner talk about optimizing business with BPM. I think that he drew the short straw as the junior guy, presenting in the last two sessions back-to-back. 🙂  I think that the two-day format is just the right length; the 2-1/2 days of Gartner last week was just a bit long. Also, starting on Tuesday so that people can travel on Monday rather than having to burn up half their weekend is nice, too.

The central theme is that the ultimate goal of BPM initiatives should be transformation, not just efficiency. As he points out, many companies focus purely on efficiency, trying to trim costs for small wins rather than looking to make a transformative change that can drastically improve the organization’s competitive differentiation and revenue. BPMS is more than just modeling and automation; it includes the whole cycle of monitoring and optimization feeding back to the modeling stage. He showed a slightly different version of the BPM maturity/adoption chart that Connie Moore showed yesterday; I’m still unsure why this is a two-dimensional graph, since it is really a projection on the diagonal axis, but I suppose a one-dimensional representation just doesn’t look as nice.

He then mapped BPM onto the “design for people, build for change” theme of the conference: UI creation and process mindset belong to the design for people side of things, whereas agile processes, SOA connections, business-friendly tools and comprehensive monitoring map to building for change. Different from, but compatible with, the view of BPM in the D4PB4C theme that I covered on slide 26 of my presentation this morning. He talked about why simulation tools are not used as widely as the BPM vendors would have you believe: they’re too hypothetical and require a certain amount of guesswork (although using detailed execution data to populate your simulation can help with this). I also think that they’re a bit too complex and analytical for many of the business analysts who are targeted to use them.

Tuebner covered a number of use cases for BPM integrated with other technologies — forms technology to integrate data from other sources, content, BI and more — and the ways in which BPM enables an improved customer experience both through direct interaction or by informing the environment of an internal employee who is dealing with the customer.

He showed (for about 10 seconds) their Q3 Wave for BPM vendors; I think that this is the human-centric BPM wave, although it really went by so fast that I didn’t catch it, much less any of the vendors’ positions on it.

He had some interesting words about end-to-end organizational visibility and how it allows executives to understand processes and systems by making the link from strategy goals down through other layers; not surprisingly, he discussed this in the context of enterprise architecture.

His final recommendations:

  • Don’t just make processes run faster, make them better and pay special attention to users’ work environments.
  • Use BPM for business improvement, not process improvement, and focus on customer experience.
  • Take an end-to-end view of process and plan BPM as a management discipline (by which he means a business initiative).

That’s it for the Forrester Technology Leadership Forum. I’ve enjoyed it, found the content solid, and the culture a refreshing change from some other large analyst conferences.

Forrester Day 2: The three B’s

I ended up skipping the session after mine at the end of the morning, but had some great hallway conversations with some of the business rules vendors who indicated that they think that I’m on track with what I’m saying about BPM and BR.

For the first of the afternoon sessions, I’m attending a panel discussion on the convergence of the three B’s — BI, BPM and BR — featuring Mike Gilpin (EA and application development), Boris Evelson (BI) and Colin Teubner (BPM). I covered a tiny bit of this topic in slides 22-24 of my presentation this morning, and will be doing a full-length presentation on this same topic at the Business Rules Forum next month in Orlando, so I’m interested to see if the Forrester analysts have the same thoughts on this subject as I do.

They start with the statement that “design for people, build for change” will drive the convergence of the three B’s. Interestingly, although a few people in the room stated that they use BPM and BI together, almost no one raised their hand to the combination of BPM and BR — a combination that I feel is critical to process agility. Gilpin went through a few introductory slides, pointing out that almost no business rules are explicitly defined, but are instead buried within processes and enterprise applications. He sees BI as driving effectiveness in businesses, and the combination of BPM and BR as driving efficiency.

Forrester will be publishing some reports about the convergence of the three B’s, and although there are some two-way combinations in vendor products now, there are no vendors that combine all three in a single product. I’m not sure that this is a bad thing: I don’t think that we necessarily want to see BR or BI become a part of BPM because it ultimately limits the usefulness of BR and BI. Instead, I see BR and BI as services to be consumed by BPM, with BI having the additional role of combining process execution statistics generated by the BPMS with other business data. An explicit question was asked about when to use the BR and BI included in the BPMS versus when to use a third-party best-of-breed BR or BI system; Teubner and Gilpin offered some guidelines for this as well as some examples of each situation, but it’s not completely clear if there’s a distinct boundary between when to use the BPMS’ in-built functionality versus the third-party specialist product.

My message on this topic is that BR is the key to process agility, and BI is the key to process visibility as well as feeding back into BR in order to further increase agility. By using the BR and BI functionality within your BPMS, however, you’re typically not getting full BR or BI functionality, but some limited subset that the BPMS vendor has selected to implement. Furthermore, you can’t reuse that functionality outside the BPMS, and in the case of business rules, a change to the BPMS’ rules often requires retesting and redeploying the process models, and does not apply to in-flight processes. However, if you’re not sure if you need BI or BR (hint: you do), then using the in-built functionality in the BPMS gives you an easy-to-integrate and lower cost way to get started. Moving to a separate third-party business rules system gives you a couple of key advantages: you can reuse the same rules across different processes and across other applications in your enterprise, and changes to the rule impacts in-flight processes since the rule is not executed from the BRE until that point in the process is reached. Moving to a separate third-party business intelligence system also provides the advantage of being able to analyze the process data in the context of other business data, and potentially feed back the results of complex analytics to inform the business rules, that in turn drive the business processes. The bottom line: BR and BI are used for many applications in the enterprise that are not explicitly process-related, or combine data from many systems of which the BPMS is just one source. For example, although there are processes embedded within your ERP system, your BPMS may not have direct access to all the information that’s in those processes and hence the BI that’s part of your BPMS can’t (easily) include that data in its analytics and reporting; a general-purpose BI platform may be much more suited to combining your BPMS statistics with your ERP statistics.

A lot of the conversation in this session, which was very interactive with the audience members, was around whether to use converged products versus separate products. It’s not a completely simple answer, and I’ll definitely be thinking about the use case boundaries between converged and separate products before I show up at the Business Rules Forum to continue this discussion.

Evelson and Teubner will be publishing an initial paper in this area in the next few weeks, using the concepts that they’ve presented here today, but see it as a springboard for more discussion in this area rather than an end-point.

Forrester Day 2: Skipping class

I skipped the opening keynote by Shantanu Nayaren of Adobe and the talk by cognitive scientist Don Norman; my presentation is at 11am, and although I’m not a particularly nervous presenter, I felt that my time was better spent reviewing my notes, especially considering that I’ve crammed material from the three one-hour webinars that I did for TIBCO and my upcoming presentation at the Business Rules Forum into a single 30-minute blast. You can see my slides here:

My only regret is missing Forrester’s opening short video of movie clips illustrating the “design for people, build for change” message; the ones yesterday were very funny, and I hope that they post them all on YouTube.