Development leaders! Project leaders and business analysts! Application and solution architects! Want to move forward on your business technology (BT) journey and be viewed by your business stakeholders as a valuable team member? Take a tip from last week's Forums held in Boston. Embrace Business Process Management (BPM) And Customer Experience. Don't ignore them, embrace them. Why? They're essential to helping you achieve your business outcomes.
I know, I know. You read the above and now think "Gee Kyle, what's next? Going to enlighten me on some new BPM or customer experience management technology that's going to transform my very existence, my company's future?"
Nope. Let me explain....
Last week we hosted more than 250 of your application development and delivery and business process peers in Boston and focused on how to succeed in the new world of customer engagement. The most impactful discussions I heard were the side conversations we held with attendees, sometimes occurring over dinner and cocktails. We didn't discuss technology. We discussed the skills your peers were developing in two fundamental areas:
BPM - no, not the technology but the Lean and Six Sigma based methods, techniques, and tools organizations use to focus on business processes and not functions; to strive for continuous improvement; and to focus on customer value.
Customer experience - defined more eloquently by my peer Harley Manning, but I'll summarize as the methods, techniques, and tools used to understand how customers perceive their interactions with your company.
Most Forrester readers certainly understand the importance of empowering their employees to contend with highly informed and increasingly demanding customers. But I’m often asked just how to overcome the process and data integrity challenges of apps or services that empower employees and/or drive continuity of experience for consumers across channels. With the rise of mobile as well as web and call center interactions and with a proliferation of new tools for managing distributed processes and data, most application development and delivery professionals as well as their business process and applications colleagues have to absorb all the arguments before they make decisions that could be critical to their firms’ futures – to say nothing of their own careers.
One pioneer whom I interviewed was immensely proud of his lightning rollout of a guerilla app to support his firm’s front office in advising clients on complex product choices. I asked him about future plans and sheepishly he admitted they would be starting again from scratch because the guerilla app was unable to leverage enterprise services exposing critical data about product offerings. He remarked ruefully that sometimes you do have to follow the IT standards “yellow brick road” rather than just head for the hills, but wouldn’t it be great to have the best of both worlds, with both agile deployment and full advantage taken of enterprise assets and data?
If you need a deeper understanding of the issues and options, then I’d like to invite you to join us at Forrester's Application Development & Delivery Forum, where my colleague Clay Richardson and I will discuss in practical terms how to deliver integrated experiences across multiple touchpoints.
Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don't trust developers. Or, borrowing from Ronald Reagan, trust but verify.
This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can't go down, and it can't be wrong.
Why Does This Work?
The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.
As British author Samuel Johnson famously put it, "The prospect of being hanged focuses the mind wonderfully."
Recently, I discussed complexity with a banker working on measuring and managing complexity in a North American bank. His approach is very interesting: He found a way to operationalize complexity measurement and thus to provide concrete data to manage it. While I’m not in a position to disclose any more details, we also talked about the nature of complexity. In absence of any other definition of complexity, I offered a draft definition which I have assembled over time based on a number of “official” definitions. Complexity is the condition of: