My keywords are: Common sense, business value, processes and business rules, stakeholder participation, architecture and structure, skill development, process testing, capabilities.

Common sense
Technology plus the ever increasing number of available methodologies could be regarded as a complete or at least sufficient toolset to deal with any number of process issues companies are facing. In fact the opposite is true: Too many toys to play with distract from what should be done and only lead to confusion. Several speakers pointed out this danger and stressed the importance of applying common sense and a ‘back to the roots’ approach. The role of business analysts and process experts should not predominantly lie in developing new methods but in solving business problems and making use of opportunities.

Business value
Really the key issue of the conference and at least during the keynote sessions the most often used phrase was ‘business value’. Does what you do and how you do it create business value? How do you demonstrate added value before you implement your solutions? Many comments by business analysts indicated that this is an area they are most uncomfortable with and pointed out that their inability to reach stakeholders and management is partly due to not knowing how to communicate the business value of their proposals, i.e. making the leap from process design to a business proposition that captures the imagination of decision makers.

Processes and business rules
This is still one of the great challenges in that both fields have progressed over the last few years albeit mostly independent of each other. But when the application of rules invokes processes and processes contain rules, independence and isolation is not the order of the day. Business analysts need to get a better understanding of business rules and rules experts need to come out of hiding. If you want processes to work and deliver you need both in combination.

Stakeholder participation
This is a subject I’m currently writing a longer piece on, so I’ll keep it short here. Business analysis, process analysis and process design all need to serve a purpose or else they are reduced to meaningless fooling around with tools. The only way to provide meaning is by getting results taken up by the business and for that stakeholder involvement is critical. I witnessed a couple of discussions along the lines of ‘we need to get management to read and understand our process models’. Wrong! You as designers or analysis need to tell the business value story and ensure that the main points are covered by your design and solution. Embed them in context, provide meaning. You may well have the best intentions for your business at heart but if you’re unable to show how stakeholders and decisions makers will directly profit from your suggestions the business as a whole will never get to see what you dreamt up.

Architecture and structure
The sessions at the business architecture summit provide some good examples of how the business can benefit from structure but they also showed some of the practical difficulties: When setting out, do you create an empty structure and try to fill it later with process, data, service and information content? Or do you base your architecture on existing processes (data,….) and build it up from there? Does architecture provide a framework for a running business or should it work primarily as a guideline for projects? There are no right or wrong answers to these questions but you do need to make sure that you have a consistent approach.

Skill development
One of my pet subjects and bbccon11 has done nothing to tell me that we are anywhere close to the skill levels demanded by the issues we’re dealing with. True, proficiency in handling and using tools is at a higher level than 10 years ago and tools and methodologies have a much broader user and fan base nowadays. But being able to drive a car when you have no sense of direction is not the smart solution. Process and business awareness should be foremost on everyones mind. Train people in process thinking and not just in how use the latest user interface. Reduce the time needed to discover current processes by making people process- instead of system- aware.

Process testing
OK, so I’m biased as this was the topic of my presentation. Doesn’t make it less important though. If your processes contain errors that will prohibit implementation, IT will need to design workarounds which in turn will increase project costs which in turn will not put a smile on stakeholders faces. The same goes for processes which may work but don’t deliver. And even if they do, if stakeholders and other interested parties had a different understanding of the problem and solution at the outset, you will not have provided them with what they expected. Process quality has as much to do with delivering capabilities as with delivering to expectations. Validation may therefore be key to your success. Likewise process dynamics. At a rough guess, every second presentation mentioned ‘global markets’, ‘changing conditions’ and ‘agile ability’. Designing a business solution without validating it against a real-life dynamic environment (simulation and stress test) means that your design brings with it the risk of limited usability. Test and check before you implement was the message I tried to get across. Of course, that’s why we set up the Process TestLab in the first place.

Capabilities
This is what the conference was all about. What capabilities do companies need? (Luckily, I didn’t get to hear any general meaningless answers but often very individual, company-specific input). How do process capabilities feed into business capabilities? (Depends on what the business capabilities are and there’s that tiny problem of translating business strategy into process strategy). What skills and employee capabilities are needed? (see above).

Summary
A lot of the issues I’ve mentioned here do not require a general state of the art solution. There already are many (too many?) tools and methodologies available. The secret lies in being smart: Smart in deciding what you need and how to create a solution using what’s already available. Smart integration. Smart processes that people want to use. Smart solutions that can be managed. We already have most of what we need but it takes brains to figure out the smart combination for smart businesses.

Other than that, I still found time to listen to Kathleen Barret ‘On the future of business analytics’. Just one quick observation as I’ll be doing a separate piece on this later. There seems to be a fundamental difference in the role of business analysts between the US and Europe. What IIBA does with regards to qualification of business analysts but also role ‘marketing’ is not something I’ve encountered before on this level. Cultural? Maybe. On the other hand there seems to be a broader gap between what BAs could do and the willingness and capabilities of senior management to actually let them do their stuff than there is in Europe.

Oh yes … I also did the first formal presentation of the Process TestLab in the US. I was fortunate enough that Roger Burlton had the slot following me where he wanted to tell ‘Horror stories from business processes’. Being customer- or in this case attendee-focused I changed my presentation in a way that would help attendees avoid appearing on Rogers list next year. Accordingly I also changed the title of my presentation to ‘The Process TestLab: How to avoid being mentioned by Roger’. This may have caused some initial confusion for attendees but at least this way the Process TestLab has already provided some valuable help

I’ll point you to Column2 as Sandy has done an excellent write-up of the presentation itself on her blog and just mention that next week I’ll be posting about a couple of the slides and topics I had to skip over due to time pressures.

BBCCon11 in short: Great event, good speakers, good opportunity to swap and share experiences … glad I attended. And who knows, maybe I’ll even make it down to the beach next year.

Most remarkable sign of conference quality? On day 1 everyone was asking ‘How are you enjoying the event?’ By yesterday that had evolved to ‘Are you enjoying it as much as I am?’

Content? Visited some great session. The day presented a good opportunity to dive deeper into selected topics. Here the gist in no particular order:

James Taylor – he of decision management fame – made one decision before his presentation and that was to use no slides at all. So we had one hour of shared experiences on decisions rules. Thing that sticks to my mind: Tons of processes are not actually processes but decisions in disguise. James made a point of mentioning one case where he replaced 25 pages of Visio process documentation with just a couple of rules.

Listening to him made me wonder how many of our business analysts are really equipped to deal with processes AND rules and their interaction.

Sandy Kemsley led yet another panel yesterday, this time dealing with the relationship between business and IT architecture. From what I gathered from the panelists comments was that there’s no real formula for success and that is very much depends on the individual situation: If you’re fortunate enough to be able to start from scratch, start with the business architecture and develop everything else from there. If you’re dealing with an existing architecture, it might make sense for IT to take the initial lead. I particularly like the comment from Forrester analyst Jeff Scott that one of the main as yet unsolved issues is the tie-in from business strategy to business architecture.

Michael S Katz gave a very insightful presentation on ‘A cloud-based system provides timely cancer care information’. The very short version is that despite a whole range of available information on myeloma (or maybe because of it?) health care providers find it hard to keep up to date with current best practices of treatment. The International Myeloma Foundation has therefore developed an application which lets patients and doctors alike interpret and evaluate relevant data by entering data into the application where it is then set against certain rules which are based on the latest and most up-to-date research. The application then comes back to the user with information on how to interpret the clinical data. Note aside: While Michael was explaining the background to the system, I was wondering about issues like security of patient data. Michael picked up on this by mentioning that the one thing they had wanted to avoid at all cost was to have a solution that would need to store patient data, as in that case billions of regulatory requirements would set in. The neat solution they found was that the input data from the patient or person making the enquiry was stored of their local devices only.

I also sat in on the CDC presentation by Dr. David Lyalin and Warren Williams, which I found very interesting as they described how they developed, distributed and applied business rules and decision tables to track immunization. I admit I will have to re-read the handout material to fully understand why they went with rules and not processes but the ability to communicate rules and decision tables more easily than processes seemed to play a large part.

I also briefly spoke with Matthew Finley, the ‘Show Director’ for the event, discussing reasons why other BPM events were usually so bland. Not sure that it’s entirely down to culture, the ‘feel’ of an event and its accessibility also play a large part which seems entirely foreign to some event organisers.

Note of interest to european readers: Despite this being a very large conference, attendees used every available opportunity to ask questions. In fact the most interesting sessions grew out of the interaction between presenter and attendees. If you’re going to these events to learn something you’ve got to be prepared to ask questions.

If you want to know more about this days’ session, I suggest you pay a visit to Sandys Column2 blog. Having the dual advantage of knowing what she’s talking about and being a woman (multi-tasking), she can actually listen, understand, evaluate, write and post at the same time – and it all makes sense.

First of all, the organisation has been great. Starting with the pre-conference information, the way speakers were taken care of and also how the conference itself put the attendees at the center of things. Next, the tracks and the various presentations the organisers selected: Quality and information content was very high and there was a lot of interaction between presenters and attendees.

The day started with a short welcome by Gladys S.W. Lam, the Conference Director describing how BBC has evolved to the present level and also making a point of continuing to develop to attendee requirements.

Next up were the three chairs of the business rules, business analysis and business process tracks, Ronald G. Ross, Kathleen Barret and Roger Burlton. In between some light banter on the relative importance of business rules vs. business processes, they defined the thread that was to run through the rest of the days presentation: It’s all about the business.

Naturally my main focus was the business process track so I first sat in on the presentation from Carla Wolfe of Elevations Credit Union. Presentation is in fact the wrong term. It was more a ‘In conversation with …’ event, as Carla was explaining how Elevations has set about putting their house of processes in order and what approaches and techniques they used. The enthusiasm she conveyed was infectious as she explained the original challenges and she got the whole company involved in rediscovering its processes. Nice touch: Mihnea Galeteanu from IBM did little more than to ask the odd question and to put up the occasional photo on the display. It only emerged near the end of Carlas story that IBM had supplied the tool to capture the processes. No sales pitch and all the more impressive for that.

Next I joined James Kobielus from Forrester Research talking about ‘Agile Predictive Process Platforms: The key to business agility’. The main point James made was that it was not enough to be able to change processes and be agile but that companies should create and use an infrastructure that allowed them to predict future developments, their impact on processes and thus providing them with ample time to adopt. Coming under the headline of NBA – Next Best Action, James demonstrated that a lot of the technology required already exists but has until now not had enough touchpoints to the world of processes – something which he says is now beginning to change. I’m usually sceptical when someone roots his case so firmly in technology but James did manage to link his case to the business perspective quite well. Is this going to be start of the art for your average company? No, but I think it might become one of the main reasons why processes leaders will gain an even bigger advantage over their competitors.

Third on my list was Clay Richardson from Forrester. Clay and I had been interviewed by Alan Earls for ebizQ’s BPM Special on process governance in the summer so it was good to meet and exchange a few words. His topic was the role of BPM Centers of Excellence to deliver transformational projects. Ever so often he made the point that simply setting up a COE was not enough but that thought should be given to its role in relation to the business departments. He made the case that the BPM COE – while staffed with competence and skill – should mainly provide a supporting and enabling role for the business departments. Rather a contrast to the clients I know where you tend to get the impression that the business departments live to serve the COE.

Finally some time to prepare my thoughts for the upcoming BPM vendor panel which Sandy Kemsley had invited me to join. Here’s how Sandy had outlined the panel session which I’ve copied off her blog (http://www.column2.com/)

“On Tuesday afternoon, I’m moderating a BPM vendor panel focused on BPM adoption issues from the vendors’ point of view. I’m a bit late with my plug for this since there was some confusion about who was actually picking the panelists (as I found out a few days ago, it was me), but I’ve assembled a stellar lineup:

• Jesse Shiah, Founder and CEO at AgilePoint. I first met Jesse back at the BPM Think Tank in 2007, when his company was still called Ascentn; since then, they’ve changed it to something that we can all pronounce while they work at turning Microsoft’s Visio and Visual Studio into real BPM tools.
• Mihnea Galeteanu, Chief Storyteller for BlueworksLiveat IBM. Besides having the coolest job title, Mihnea and I both live in Toronto, so have the advantage of being able to really put “social” into BPM by meeting for coffee to discuss how IBM is making BPM social with BlueworksLive. Yes, I make him pay for the coffee.
• Jeremy Westerman, Senior Product Marketing Manager for BPM at TIBCO. Part of TIBCO’s “British invasion”, Jeremy and I have a long history of me asking him about what’s coming up in their product releases (such as “how’s that AMX/BPM to tibbrintegration coming along?”), and him trying to say things that won’t get him in trouble with TIBCO’s legal department. Obviously, he’s a big fan of my “everything is off the record after the bar opens” rule.
• Thomas Olbrich, Cofounder and Managing Director at taraneon. Unlike the other vendors on the panel which provide implementation tools, taraneon provides a process test facility for process quality, meaning that they have the best process horror stories of all. Thomas is the only one of the panelists who I haven’t met face-to-face before now, although I feel like I know him because of our lengthy Twitter exchanges, only some of which are about shoes.“

I’ve sat in on these panels often enough and in the past there have been occasions when panelists should have been asked to check their weapons at the door: Vendors trying to outdo each other and boring the audience to death, your truly hitting out at the vendors (the privilege of being the odd man out) for failing to understand the business perspective. Not so in this case. I think it’s a definite sign of how far these products have matured over the past years that vendors can now afford to address the business concerns of their clients. I made the point that in fact BPM systems had now reached a point that there was a danger that clients lacked the ability to handle them. Improving process awareness (one of my favorite topics) is what I think is urgently needed. Tongue in cheek Denis Gagne asked from the back row if we might not also consider dumbing down BPM systems.

Rest of the day was spent getting to know new contacts, reacquainting with former friends and collegues and enjoying the wine provided by IBM (yes, they get an extra mention for that). Lots of new ideas which unfortunately led me to do a redraft for Thursdays Process TestLab presentation on process quality. (11:30am, Room Diplomat 1)

Final thought for european BPM conference organisers: It does make a noticeable difference to the general mood when conference attendees are not simply treated as a source of income. Day one was dominated by smiles from attendees, chatting about their experiences, finding the presentations as enjoyable and equally important as the networking. Customer orientation is not only a BPM issue, it should also be an issue for conferences. The team at BBC have done a great job.

Phase 1 of the survey saw us conduct in-depth interviews with representatives of various companies.

We have now started phase 2 in which we’re asking for your participation in our online survey. Please visit

www.q-in-bpm.org

and share your views and experiences. All registered participants will receive a detailed summary of the survey results, allowing them to benchmark themselves against the overall results.

“As Niel Nickolaisen says at SearchCIO, The best BPM implementations focus on keeping things simple, "My ‘fix processes before implementing technology’ attitude has influenced how I view such things as BPM systems." So do you think processes should be fixed before implementing a BPM system?”

Here’s what I wrote in my response:

Fixing processes comes in two parts. One deals with logical errors in the sense of processes or parts of them not working, not delivering the required results or functionalities. The other aspect deals with the improvement of existing and basically usable processes.

What we tend to see is that broken or unusable processes are fixed to the extent that they can be implemented. Curiously, this usually comes under the headline of business process improvement even though you’re not really improving the business process but only making the BPMS deployable.

The downside is that (technical) BPMS restrictions either lead to a change in the minimally repaired business processes (resulting in BPMS being blamed for performing below expectations) or in perpetuating the quick-fixes.

Unfortunately [and contrary to the expectations the BPMS industry has created], we are still unable to conduct the process equivalent of open heart surgery. Once implemented, most processes have a smaller change and update rate than processes not tied to a system. This may in part be down to the BPMS but it’s also down to the mindset and methodology employed.

In practice, most still regard the ‘process’ from design to implementation as a one way street with a definite and defined ending: The release of the BPMS supported process.

Were you to regard it as a life CYCLE and continuous task instead you could probably improve/fix a lot of process aspects after an initial implementation.

But again, looking at real life what we see is that the technical aspects (need a new button, can you change the layout of the screen) are changed and tend to get confused with the business process requirements.

The long and short of it all is that the garbage-in garbage-out argument may in some cases be valid and in others less so. This unpredictable state requires a thorough assessment of the risks and consequences involved in fixing problems before or after process implementation.

While I was putting down my thoughts other replies flooded in, creating a very interesting discussion that might get you to re-think how to approach process improvement and automation projects.

As this issue is something we deal with on a daily basis, why not pop over to the Process TestLab website to find out more on how you can improve the quality of your processes prior to implementation.

Now, everything about this story must currently be regarded as speculation including any conclusions we may like to draw from what has been reported.

But should the reports prove to be true, it must surely be seen as another indication that companies are not paying enough attention to processes or rather that behind the process facade their building contains few and only crumbling structures.

How can it be that a process using a regular transaction platform is not tied into the audit and control processes in a way that these processes actually perform? This question may not be all that difficult to answer. Could it just be another case of isolated process silo thinking coupled with a lack of responsibility? I know I made fun of this in my last post “BPM: Take me to your leader”, but that was three days ago when I had no idea that the UBS case might just be another example of paying lipservice to the process vision while having no real idea what processes are all about.

Whatever the defects in the actual audit and control processes at UBS, the even more pressing problem is that the interaction between the controller and the controllee seems to have failed. So the very real question is: How did UBS validate its processes before putting them into practice? Did the validate them at all? Or did they look at the process models and like the colors they were drawn in? Did they even look at how one process affects the next? Looking at the result (remember, this is still all speculation at the moment), it’s hard to imagine that any meaningful process testing has ever taken place. Hardly surprising when the dominant attitude is ‘seen to be doing something’ rather then ‘doing the right thing because we understand the need’.

So, it all this going to hurt UBS? The most damming answer may have come from an unlikely source: “Moody’s said that although UBS was strong enough financially to absorb the loss, it had concerns about its risk controls. We have continued to express concerns with regards to the ability of management to develop a robust risk culture and effective control framework," the agency said.

In other words: UBS will survive (which is good) but lacks the ability to change (which is not good).

Would you now like to reconsider the importance of process quality testing? If so, visit the Process TestLab and let us discuss how we can help you.

Update Sep.17: Readers may also like to consider the observations made by Gary Comerford in his excellent post "The two axioms explained"

Links:

BBC report: UBS trader Kweku Adoboli charged with fraud

taraneon Process TestLab: www.processtestlab.de (german language) or ptl.taraneon.com (english language)

Process Cafe Blog: "The two axioms explained"

What follows next will probably be similar to a conversation I had last week with a person who – at least by title – is responsible for a decent part of the processes of a major european financial institution.

Me: So you’re the guy to talk to about processes?

Him: Well, officially yes. But for the next 2 years I’m tied up in a non-related project, so I can’t really help you.

Me: OK, so who do I talk to instead?

Him: If it concerns processes, you’d need to talk to every single team leader, plus the heads of department and don’t forget the governance and compliance folks.

Me: How many people would that be?

Him: Uh, about 600.

(It was then that I decided to at least have some fun, seeing that this conversation wasn’t getting me anywhere)

Me: The reason I’m calling is that I wanted to offer you the process equivalent of the holy grail and I just wondered who best to talk to and by the way, I’ll be meeting your CIO next week.

Him: Can’t really help you I’m afraid. Everyone at the bank is doing their own thing with processes.

Me: Why?

Him: Because they’re important.

Me: Oh right. So … you’re not interested in the holy grail, you can’t point me towards someone whose job it is to be interested but all the same processes are important? Doesn’t that strike you as weird?

It was at this point that we decided to change the subject. He wasn’t trying to get rid of me, he just couldn’t help me.

Now I wonder how the aliens would have reacted. Would they have continued to talk about the weekends football results like I did or would they have gotten on their spaceship again, taken to the skies from where we would then have heard the quiet order: “Prepare laser and EXTERMINATE”?

Images (thanks for those childhood memories):
Tardis: http://strangebuttrueradio.blogspot.com/2011/05/eastbourne-east-sussex-england-tardis.html
Daleks:    http://tardis.wikia.com/wiki/Evolution_of_the_Daleks

The effect is overwhelming: Whereas before people had to struggle with interpreting abstract process models, now they can understand the logic and dynamics of a design by working ‘in’ the process rather than by looking at the model. Imagine taking the design template of a new car for a test drive and you get the general idea.

But how does process validation at the Process TestLab work?

Let’s take the most common case that a project team has developed a new process which needs to be validated before it goes into the next phase. Our approach makes it very easy:

1. Process design models and descriptions are sent to the Process TestLab
2. At the Process TestLab, we transfer your process designs onto our validation system. This usually takes only a few days.
3. Next, we set up a temporary validation environment at the clients site. Not to worry, all it amounts to is a room into which we place our validation server and a network of terminals. Setup usually takes no more than a couple of hours.
4. Then the actually process validation by the client takes place. Every participant is assigned a process role (e.g. sales rep., clearance team member etc.).  Our validation system then generates process instances and the server routes the instances from participant to participant, following the logic as described in the process design. The participants can work on the assigned tasks, enter data, in fact they can do everything necessary to evaluate the process logic.
   Our job at this stage is simple. We just guide the validation team through the process and record any upcoming discussions. After all, our clients are the experts on their own processes.
5. During the validation runs, we automatically record the audit trail of the process and add any comments made by the participants. This way, our clients receive a complete documentation on what aspects of a process may require changes and in which context these items came up.
6. Finally, we dismantle the validation environment and generate the final validation report for our clients.

Thus, with a minimal amount of time spent, our clients

• have validated their processes by having actually worked in them instead of only looking at the description,
• have avoided the pitfall of interpretation,
• have jointly identified areas to sign off on and areas that require additional work,
• have created a group consensus on the process design.

Our approach lets our clients quickly ensure the integrity, workability and above all usability of a process design without them having to it implement it on their IT. As we all know, this helps avoid unnecessary costs [2] and helps reduce the time needed to implement and roll out the process. Best of all, as quick as our validation process is, you can use the Process TestLab in parallel to your projects. It doesn’t even conflict with your project schedule. And thanks to our mobile validation enviroment, we can support our clients anywhere in the world.

Links:

[1] Visit the taraneon website

[2] This short animation explains how process validation can help you avoid unnecessary effort and cost

Our analysis at the Process TestLab show that there’s certainly a lot you can do a) to avoid process errors and b) (maybe even more important) to reduce the impact and consequences.

The logic is irresistible: The later you discover process design errors, the more costly it becomes to correct them. Putting in a wrong beam can be easily rectified when your still in the preliminary building works phase, it’s only when you notice the mistake after work has been completed and you’re all ready to move in that the consequences will really hit you. Now it’s become not only an issue of changing the beam, you might have to take off the roof and take out a few walls just to get to the beam.

The obvious conclusion? Conduct mandatory quality checks along the way. From the architects design – your business process design, to the builders plans – the IT design, to the actual building process itself until you can sign off on the actual building itself.

So why isn’t this commonly applied to business processes? Maybe it’s because we’re simply unaware of the sheer scale of the problem. So let’s look at a few numbers:

• With an annual investment of around euros 6bn into process projects in Europe alone, a success rate of 20% means that you’re not getting your moneys worth on 5 bn euros.
• Of the remaining 80% a large percentage of projects can be salvaged – but at a cost. The cost of correcting a process design error during the operations phase against during the design phase is on average 75 times higher.
• All through last year, we published our process quality barometer on a monthly basis. The annual average revealed that 90% of all processes checked at the Process TestLab contained design errors ranging from ‘simple’ to ‘can’t be implemented’
• Bent Flyvbbjerg and Alexander Budzier analysis of more than 1.400 projects report in a new study in the Harvard Business Review that “Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.”
• Gartner Group also rang the alarm bells earlier this year by stating that “Overlooked but Easily Detectable Business Process Defects Will Topple 10 Global 2000 Companies Between Now and Year-End 2014”.

Many customers we talk to will at first refuse to accept the extent of the problem. One reason may be that costs for change request are usually not charged to the project budget – indeed, if the errors resulting in change requests only come to light during operations, there’s no project left. In that case costs will be regarded as operational expenses and get lost in the day to day business.

Another possible reason was mentioned by Mike Gammage on his blog when he said: “But maybe there’s an even deeper reason for clinging on to things as they are and rejecting the wider perspective. Projects – even big ones – are quite comfortable places to be. There’s a seductive sense of certainty and control.”

Errors and mistakes get made. Even with the benefit of hindsight we have to accept this as a fact. But there’s a world of difference between “Making Mistakes” and “Detecting Mistakes”. That is why the Process TestLab has developed a range of services to test, validate and simulate processes for all phases of your process lifecycle. Check first, it’s cheaper in the long run.

Links and recommended reading:

taraneon Process TestLab: Process Quality: More than a formality

taraneon Process TestLab: Homepage of the taraneon Process TestLab

Harvard Business Review: Why your IT project may be riskier than you think

Gartner Group: Overlooked but Easily Detectable Business Process Defects Will Topple 10 Global 2000 Companies Between Now and Year-End 2014

Mike Gammage: The root cause of IT failures