How many times have we seen high profile people do things that contradict the messages that they send to us? We have seen a homeland security official stalking teenagers on MySpace, we have seen athletes deny taking performance enhancing drugs only to be proved guilty, and we have seen laws like the Patriot Act, which was supposed to protect us, actually violate our civil liberties. What does this have to do with technology you might ask? Well the lesson learned here is if you say one thing but do the other, the people who follow you lose faith and your initiatives fail.
The same holds true in corporate America. When a visionary leader attempts to implement a culture changing initiative like business process management, agile development, or a new project management methodology, they must practice what they preach. I have seen several attempts to implement standard software methodologies, like CMM, fail. Why do they fail? Because the visionary leader didn't practice what he preached. In this example, the visionary preached that by adopting CMM, IT would be more successful in delivering projects. Unfortunately, implementing CMM was not carried out like a project. No scope was defined, no communication plan was developed, no stakeholders or executive sponsor was named. Instead , a boat load of documents were thrust on the IT staff. Of course, there was mass resistance and the initiative failed. Had the visionary practiced what he preached and used CMM to implement CMM his chances for success would have greatly increased.
Practice what you preach applies to those trying to implement SOA for the first time. You probably sold management that some of the advantages of SOA are speed to market and agility. The CEO was so excited by your presentation that he freed up a boat load of funds to launch your SOA initiative. Guess what? It's now time to get agile. Practice what you preach. Throw away your old waterfall approach. Gone are the days of 6-8 month deliverables. Start delivering early and often. If you don't change your ways, the CEO will quickly lose faith in this initiative quicker the you can say WMD.
If you are one of the many enterprise architects who have great visions of what SOA can do for your organization, but can't find anyone in the organization to provide the financial support needed to bring SOA to realization, listen to this real life story of how you can get the business to go to bat for you.
A medium sized company, who will remain unnamed, was supporting a sophisticated, proprietary supply chain system that was taking an army of developers to keep it running. The business was changing rapidly and the demands for new features and enhancements were far exceeding development's ability to meet the customers' needs. The system was several years old and needed to be integrated with several other silo legacy systems. The UI was not user friendly and was in dire need of workflow capabilities. The business wanted something to change but did not want to sign up for another long painful rewrite. So IT turned this liability into a win-win proposition for both the business and IT. Here's how.
First, IT put together a cost/benefit analysis for only the IT side of the equation. There was a huge opportunity to reduce the amount of resources required to maintain the legacy system while providing business value by improving speed to market, increasing new development capacity, and improving quality. When presenting their findings, the IT group pointed out that they thought there were even more substantial opportunities on the business side of the equation if the business would evaluate their existing, 20 year old processes.
After convincing key executives in both the business and IT that a large opportunity existed, the business funded the first phase of this initiative and brought in an outside firm to perform a business process analysis. In just 90 days, the current state and future state business processes were modeled and a few compelling opportunities were discovered. What the business discovered after interviewing numerous people throughout the organization, including several customers, was that their existing processes where not only costing more then twice of what the future state would cost, but they were potentially limiting the company's ability to create more sales.
At the end of this phase, the major IT and business stakeholders held a future state design meeting. In this meeting, the business discussed specific use cases that they needed in the future state that would allow them to reduce costs and increase revenue. For each use case, IT would describe the technology required to satisfy the use case. The use cases contained items like wizard based data entry forms, visibility into orders, B2B web interface, operational reporting, and integration with several legacy systems. IT was able to map those use cases to a BPMS/SOA solution to create a robust, user friendly, workflow system that could be deployed rapidly without rebuilding years of legacy systems. What the business heard was BPMS and SOA would answer their prayers.
The next step was to sell the CEO and his leadership team on how the company could be transformed by reevaluating its business processes and applying BPMS and SOA to help the business achieve its goals. It was the business and IT, hand in hand, selling this idea to the executives. The sell was easy and the company has moved on to the next phase with sufficient funding and executive level support.
I know this was a long story but here is the point. The IT team knew for 3 years that a BPMS and SOA solution was the answer to the problems that they faced each day. But IT had not figured out how to sell it and how to fund it. Finally, the pain became so great that IT realized that they had to figure out a way to sell these concepts to the business. First they showed that the cost/benefit just in IT was substantial. This got people's attention. Once they got people's attention, they were able to engage the business and gave the business ownership of transforming the company. Once the business had bought in, the rest was history. So what is the moral of the story? Aligning technology with real business cases increases your ability to sell technology to those who write the checks.
Many companies in the early phases of the project management maturity model rely totally on ROI (or sometimes gut feelings) to prioritize their projects. But does ROI tell the entire story? The ROI is just one piece of the business case that should be presented before a project gets approved as part of a company's portfolio. There are at least four categories of business drivers that should be considered:
1) Financial Analysis
2) Strategic Alignment
3) Tactical Importance
4) Risk Mitigation
When looking at the financial aspect of a project, key metrics like Net Present Value (NPV), ROI, Payback Period, Cost Avoidance, Cost Reduction, and Opportunity Costs should be considered. Things to consider in the Strategic Alignment category are business fit, customer retention or growth, revenue growth, new markets, customer satisfaction, or other important business drivers that come straight from the company's goals & objectives. Then there are the tactical drivers like improved performance or quality, longevity, competency enhancing, competitive impacts, improving time to market, or first to market to name a few. The fourth category is for business drivers that mitigate risks for business issues. Regulatory compliance (SOX, HIPAA, etc.), business continuity, disaster recovery, security, and patent protection are a few that come to mind.
Each company should have specific business drivers that fall into these four categories. All of these drivers should be evaluated in the business case that gets presented to the business owners of the portfolio. The business should tailor the specific drivers within each category to meet the overall company goals and objectives. Then weights should be assigned to each business driver.
Here is an example: Let's say that Strategic fit is a driver you wish to measure. You can apply a weight of 1 for low, 2 for medium, and 3 for high. For ROI or NPV, set some thresholds for low, medium, and high (low < $1M, Med < $10MM, High >=$10MM for a small company). After entering in all the weighted business drivers, sum up the total for each project and you get the Net Weighted Portfolio Value (NWPV).
If your company does not own robust portfolio tools, you can simply use Excel. To test this out, take what you think are the top 10 projects in your company and enter all of this data in the spreadsheet. Then sort by the NWPV and see how this compares to the original top 10. You might be surprised.
Keep in mind that the NWPV is for guidance purposes only. The CFO's pet project may still be #1 but at least you gave him visibility into the value of all of the projects in your portfolio. The intent is to put all projects on a level playing field so you can use more then the standard ROI or gut feel to prioritize your IT investments.
References
Kaplan, J. (2005). Strategic IT portfolio management: Governing enterprise transformation. PRTM,Inc.
Handler, R., & Maizlish, B (2005). IT portfolio management: Unlocking the business value of technology. John Wiley & Sons.
The new craze in America is a heavy diet of BlackBerry. BlackBerry for breakfast, BlackBerry for lunch, BlackBerry for dinner, BlackBerry during meetings, BlackBerry in line at Disney, you get the point. How have we become so addicted to our BlackBerry mobile devices?
I was recently at a BPMS Summit in San Diego. Every morning for breakfast they herded us like cattle into the breakfast area where they set up "networking" tables by industry. I sat down at the CPG industry table expecting to start up some meaningful "networking" discussions with some of my customers and peers. What I found was six people at my table buried in their BlackBerries. "Good Morning", I said. Four of the six looked up, smiled and acknowledged my existence. Then they hurried back to their life support systems in case they missed in email in that brief second that I interrupted. I started eating my breakfast as all eyes focused on their life support system with their fingers working their magic on these evil devices. After a few minutes of silence (other then me munching on my granola) I asked, "How have you liked the summit so far?", to the lady to my right. She peeked up and said it was nice. After another minute of small talk she hurried back to her wireless addiction.
I attended session after session of really good information about BPMS, SOA, change management, and many other topics for the next 3 days. What amazed me is that several people spent $1800 in conference fees plus T&E just so they could read their BlackBerries in the Sheraton Hotel in San Diego. What's up with that?
Maybe I am too old school. After all, I have only owned a Tivo for 8 months now. Have you ever spent hours getting your Power Point ready for a meeting only to find a bunch of people tuning you out to their BlackBerry when you speak? Have you ever sent emails to someone who you know is in an important meeting and get an instant reply? There ain't a whole lot of listening going on!
Let's do some math. Let's say the average senior management type person gets 120 emails a day (probably a very conservative number). In an 8-hour day that's 15 emails an hour or an email every 4 minutes. If that person is on a heavy diet of BlackBerry, how much information other then the emails is that person actually processing throughout the day? Not much. Maybe that's why they need so much email....to get them up to date on what's going on.
I have read in so many books, articles, and blogs that email is no longer a good form of communication. If you really want to get a message across you need face to face interactions and you need to establish relationships. That is exactly the opposite of what the BlackBerry Diet gives you. So I ask all of my fellow bloggers, is the Blackberry Diet ruining corporate America's ability to communicate effectively? Or, am I just behind the curve like I was with the Tivo?
I am beginning a long journey to implement both a BPMS and SOA solution at work. What I am finding out is that the technology is the easy part (and it is not all that easy). The real key to success is change management. The reason I say that is when I list out and rank the barriers to success, the top 5 are not related to technology. Number one: Resistance to change. Number 2: Becoming a process centric culture. Number 3: Governance. Number 4: Conflicting project priorities. Number 5: Lack of in-house skills.
If you look at this list you can see that all of these issues are related to people and processes. Change management, by definition, is managing the human aspects of change. The 5 barriers I listed are all issues that need to be addressed by either changing the culture, changing the organization structure or processes, or by training people. If we don't address all of these issues up front, then our chance of success is greatly reduced.
I am confident that we will successfully tackle the technical challenges, but we will need some help with the big 5! Any advice would be greatly appreciated.
A few years back, many "experts" were telling us to build systems to last. Fast forward to 2007 and the message is clear: Build to Change!
In the age of the ever demanding users, requirements change quicker then the ink dries on your last requirements document. In the days of "Build to Last" we would anticipate every users' needs and build the "ultimate" solution so that we would not have to spend a fortune maintaining it. The end result, we built more stuff to maintain then we should have.
Taking the Build to Last approach is like buying your 4 year old adult clothes hoping that they grow into it. Technology is changing so rapidly you can't possibly anticipate user needs. Take the IPod for example. Do you think that you have purchased your last MP3 player when you bought your Nano? Did you realize that in 3-5 years a hard disk will be a thing of the past like my old 8-track player. 3-5 years from now you will be laughing about only being able to store 4000 songs on your IPod and you actually had to burn songs to disk instead of virtualizing them in memory. In fact, the only device you will carry will be a phone and it will be your debit card, MP3 player, mobile computer, and much more.
So, my point is, don't try to think too far out in the future because the future will be totally different. Build to Change and move towards a service oriented architecture. That way, when the technology changes, your business processes and rules can easily adapt to the new and emerging technologies of tomorrow.
As vendors start embracing SOA, Software as a Solution (Saas) will become commonplace in the near future.
Every tech magazine has article after article on SOA and how its transforming businesses. Companies selling packaged software are early adopters of SOA. If you take a step back and put your Tivo on slow mo, can you see what the next wave is? In my opinion its SaaS. As vendors continue to create more process centric and service enabled products, it is becoming increasingly easier to integrate not only with the 3rd party packages but with services within those packages. If payroll is not your core competency, why fill your data center up with servers and packaged software when you can call payroll services from the vendor's computer center and display the contents in your own portal? Look at all the money you can save by not having to manage and maintain the application, the servers, and monitor the performance. No need to pay for disaster recovery or business continuity, the vendor can provide all of that. How much money can you save in electricity, human resources, floor space ,etc.?
Has the light bulb come on yet? How is this different from hosted solutions known as the ASP? In the ASP model, the software solutions are confined behind the vendors walls. Your applications cannot directly communicate with these systems. What's worse is you probably have some ugly batch extract processes that feed data between your enterprise and the vendor. Then you have batch jobs that run at night and post updates. This can create synchronization issues and move you further away from the goal of having "real-time" data. With SaaS, your systems can integrate seamlessly with the vendors services and the need for the ugly extract processes go away. The SaaS solutions can integrate with your systems real-time making the user experience much more productive.
Is it here yet? Almost. Most vendors are in the early stages of the SOA maturity model. I predict that in the next 3-5 years, SaaS will be as common as the IPod is today. For now, all we can do is plan for the future. So, get your applications service oriented now so you will be ready for the SaaS age.
BPM is taking IT by storm, but are the vendors ready for prime time?
I spent last week at the Gartner BPM Summit in San Diego. If you have never been to a Gartner Summit I highly recommend it. For three days I listened to Gartner analysts, industry experts, and a few customers talk about the benefits of BPM and how corporations need to become process centric to survive in the upcoming years. BPMS vendors are popping up like weeds as everyone is trying to get a piece of the new multi billion dollar pie that is fresh out of the oven. Every day at lunch time I wandered down stairs to the vendor pavilion to catch a glimpse of the new silver bullet. On my first visit to the pavilion I expected to see a dozen vendors come rushing towards me. What I saw was over 40 booths comprised of companies ranging from billion dollar giants like Microsoft, IBM, BEA to little known pure players like Sunguard and Singularity. What I learned was even more surprising. Pure players like Pega Systems, Lombardi, and Savvian have far superior product offerings then IBM, Microsoft, and Oracle. All three of the billion dollar giants I mentioned have recently purchased pure play vendors and are still a year or two away from making a huge impact in this space. BEA, however acquired Fuego last year and is already one of the favorites at the show.
Another thing I learned is that even the stellar pure players are early in the maturity cycle. Many of them, like Appian, grew up delivering solutions targeted at a certain industry. For Appian, government was its major focus. Other pure players lived solely in areas like supply chain or finance. What you will see over the next two years is two things. First, pure players will work hard to round out their industry experience and provide complete solutions. Second, many of these pure players will get gobbled up by the big boys. I expect next year's summit to only have 30 booths and the year after that might only have a dozen.
What does this mean to the buyer? If you can afford to wait, which many of us can't, wait to see which vendors are left standing a year from now and evaluate how well the large companies have integrated the pure players into their product offering. If you can't wait like me, then I recommend looking at BEA and some of the more dominate pure players like Pega and Lombardi. Regardless of which path you take, make sure your vendor of choice uses open standards like BPEL and XPDL in case you to need to migrate to another tool down the road.
