The joy and pain of rolling out a new business system

As three months in Mexico City draw to a close, the business process management (BPM) based system we've been building is heading for production. Not wanting to risk jinxing it (so there is a lot of wood touching happening here), I am trying to avoid saying that it may possibly, if the stars align, be on time and to budget. Technolab and the large multinational insurance company that we have been working for should be proud, as even if we do see a last minute hiccup, the teamwork and desire to get the job done has been incredible. So, that's the joy over with. What about the pain?

The pain (at least for me) comes from the uncertainty; the last minute unexpected mishaps; the possibility that the production servers just won't run right; the fear that integration with the system of record is just not the same for production as in dev and test; the fact that I'll have to perfect meditation to try and sleep without my brain going over every last detail (again). Dreaming software is not fun or relaxing. Especially not dreaming it in a foreign language!

But its just an application, right? And its been tested?... Of course.

Its the fact that the system touches the working lives of practically every skilled worker from sales, through underwriting, to policy issuance and accounts receivables. If the system screws up (like throws every item of work into an error state) for some unforeseen and therefore untested reason, there's going to be a lot of people sat on their backsides drinking coffee and waiting. That would not be the ROI that we all hope for. But its not just this project. For me, every system I've deployed (more successes than mishaps, it has to be said) leads to this mix of adrenalin and some other unknown compound (probably caffeine).

So for now, all I can do is keep on using the revolving brain, mentally touching and prodding every last piece of the processes and applications, to satisfy myself that everything is good. Reality is, its been good for a while. We have settled, just in time, into the essential phase of stabilization and risk reduction. So I'm ready for some joy on Friday. Just a little. Seeing the first users successfully login and start working full time, full on, with their new system. If so, you could see a deliriously happy post from me at the end of the week. Please keep your fingers crossed! Mine are, and its making it difficult to type.

A post from the Improving It blog

Testing times: changing perspectives in an agile development cycle

Testing software, in the form of products, custom applications or BPM based process implementations is surprisingly very different. I watched skilled, professional testers provide amazing coverage of a product in my previous life as product manager, with automated tools preventing regression. I've been part of teams building custom business software, then working hard on testing that software so it gets through the final user acceptance without a hitch. Right now I'm working with a client to ensure that the BPM and Case Management solution we built, following an agile methodology, not only meets user requirements, but works without fail. It is this last one that has presented some interesting challenges. How do you transition from an iterative, modified scrum development model, to the formality required to ensure the solution that has evolved just works? This is hard for the analysts and end-users, and surprisingly for the developers as well.

The head of the systems group pointed something out to the team of end-users who have been working with us on the project since day one, and who have now been enrolled as testers. Paraphrased (fortunately, because the Spanish translation would have been bad) he pretty much said,

You've had your chance to say what goes into the solution. Now test what we've been delivered, not what you wish you'd asked for 6 weeks ago. Now is not the time to be suggesting new requirements, or complaining that some things are more difficult to do than you would have hoped. If you can work around a limitation or restriction, you will. Feel free to note potential improvements and we'll rank them for phase two. If the solution does not work, throws an error, or completely blocks work from moving from one activity to the next then your tests have been successful. The aim of this exercise is to come out the far end with a system we can be confident will work in production.

I have a lot of respect for that attitude, especially when it comes from the guy who is paying the bill for the solution that is delivered. Pragmatic, realistic and most likely to lead to a project that is delivered to time and budget, while meeting 90% of the user requirements. It also helped the end-users adjust their perceptions from creative and business minded analysts, to logical and step by step testers. They are testing with real data and documents, which will hopefully uncover any hidden data level issues, but will the test cases cover the 90% of insurance underwriting tasks they have to cover day to day? If you see the work-arounds they have to do today with their paper and 'systems', you'd think it would be hard to fail.

We have one thing on our (the consultants') side, which is the same thing that always represents a risk. The previous paper process effectively had no automated controls, but because of that it meant that you could do whatever was needed to get work done. We've added some controls and rules. In fact over the course of the project we've added, then refined, and finally removed many more. As expected, at the start of the project the appeal of being able to control and restrict a process and its flow was exciting for the users and analysts. They define many things that they realize later on just won't work in practice. The trick to this is helping them understand that this is a step forward from today and flexibility is a positive thing. And fortunately it means that the likelihood of testing failing due to poorly implemented, highly complex rules is much reduced.

So, my beloved user testing team, please beat up our solution this week, with logic, flow and some flair. 'Cos its a damned site easier to fix big problems now than after go live!

A post from the Improving It blog

BI and BPM is more than slicing and dicing your workers

What does Business Intelligence (BI) get a business? Incredible insight into the performance of the business, its operations and the impact these things have on the bottom line. Which is great, until it shows that certain parts of your business are really messed up or just extremely unpredictable (which when you are trying to achieve consistent results can be a problem).

So what do you do now? Find a way to improve the performance and repeatability of business operations and find a way to get visibility into the opaque areas that are causing you so much unpredicatability. Both of these are targets for Business Process Management (BPM) tools, since improving and automating processes can provide huge benefits in the way operations run. Great story. The end... But not quite.

Its okay. I don't have a marketing team watching over my every word, so I don't have to claim that BPM solves everything, since it doesn't. Vendors and consultants forget that BPM needs to truly be part of the BI landscape. And not the vague attempts some BPM vendors have made by trying to force fit analytics tools onto process engines to provide in depth slice and dice information on the performance of individual workers. In my opinion, this is missing the point.

What do I mean? I'll answer a question with a question. What value is there in pumping basic activity timing information from your BPM engine into a multi-dimensional cube so you can analyze the crap out of an individual step in a process, when you can do much of the same with standard BPM database tables, and an Excel pivot table? Unless the process represents millions of items a day, the level of scrutiny that analytics can provide at such a granular level is potentially misplaced. BI is not just having a cube and putting some pretty visualization in front of it.

Here is what the true intersection of BI and BPM is in my opinion. It is the ability for BI to help you identify where in the business you can see problems, then using BPM to rapidly:

• Design, implement and run improved processes to help fix the problem
• Provide visibility into the work inside the process at a point in time with real business metrics such as the value, risk and profitability of that work
• Enable individual work items to be profiled and prioritized (against these business metrics) to drive the process towards greater profitability or revenue
• Track information that can rapidly feed back up to your core BI, to show how performance and business metrics are trending

Using all this great BPM value, make sure that BI shows meaningful information from it. Down in the business operations, a KPI is maybe that the average time to process a specific three steps in the process has trended above 15 minutes 53 seconds. The manager there can work with that to fine tune the process. But I don't suppose the guy with a corner office 12 floors above really gives a crap. His question is whether the same operations are going to hit a profitability of 18.5%, a growth in revenue of 6% and reduction in costs of 2.5%. And what the hell can be done about it if it appears that's not the case, because that's one thing that will impact his bonus.

BI and BPM are complementary at many levels and should feed each other in many directions, and it takes more than a software vendor to make this a reality. Implementing both technologies to best effect in their disparate business environments, while ensuring that the sum is greater than its parts is a challenge. So maybe it is time for a few more consultants that understand both BI and BPM to help companies really see the potential.

A post from the Improving It blog

Download the podcast of this blog post

P2P payments without the PayPal

I had never thought of alternatives to PayPal that maybe my parents would trust. When it comes to sending money around, people are rightly cautious when it comes to the use of third-party services. And unfortunately PayPal has become a target for a large amount of phishing scams, unfortunately hurting their image through no fault of their own. It seems though that other people have been thinking of alternatives.

Yesterday I received a message from CashEdge, (who I mentioned in this blog in 2006 and it appears their PR team still has my name on file. The power of PR; it got you another mention!). They are talking about an new approach to person-to-person money transfers that could be offered by banks - i.e. the bank you already know and trust with your hard earned cash. It certainly sounds appealing. So what's the deal? According to CashEdge:

Today, CashEdge launched the first person-to-person payments service for banks – POPmoney – that will enable consumers to send email and mobile P2P payments directly from their bank account to friends, families, and others, using only an email address or a cell phone number. There has been a lot of buzz about P2P/mobile payments recently, but CashEdge offers three critical advantages: 1) POPmoney is the only service built specifically for banks; 2) CashEdge has a proven record of success in providing risk-management money movement services to the top national banks; and 3) unlike other payment networks, banks have a built-in customer base (current bank customers) for this service.

http://www.popmoney.com/media.html

So this sounds like a good idea for US banks, which are still tied to paper checks (cheques) and are desperately trying to find faster ways to move consumers away from them. It sounds like a potentially great source of new revenue which is effectively lost today to PayPal. And from what little I know of CashEdge, they have the ability to provide this solution to mid-tier banks that don't want to build it themselves, as a software as a service (SaaS) offering.

For me what will make or break it is not CashEdge, or the announcement of an offering that does not expect to have customers it can name until the summer (in which hemisphere?), but the pricing that banks attach to the service. Will they try and undercut PayPal, or will they charge a premium, knowing that mom-and-pop wouldn't use PayPal anyway. Go too high and mom-and-pop, with plenty of time on their hands will probably write that check, stuff it in an envelope and put a stamp on it.

Good luck CashEdge, but I'll believe it (POP) when I see it unfortunately and will happily continue using PayPal for now. That feeling is only reinforced by an announcement that seems way too early, or at least a missed marcom opportunity in the buzz and advertising strength of a bank saying, "Use our great (POP) service" and other banks saying, "How do we do that?". The credibility of P2P payments (at least in the US) rests with the banks, and their adoption of CashEdge, or other vendors that have been pre-warned that they have until the summer to make an announcement first.

A post from the Improving It blog

Download the podcast of this blog post

Tools are 'temporary body parts' (so pay attention to application design)

The BBC News website had an interesting story today: Tools are 'temporary body parts' The researchers writing in Current Biology showed some interesting, if not completely surprising results that after using a tool for an extended period of time, your ability to perform similar tasks without the tool become slower and more 'clumsy'.

"There is a great debate in neuroscience about the representation of the body and representation of space," said Lucilla Cardinali of the National Institute of Health and Medical Research (Inserm) in France.

The researchers were working with a metal grabber and seeing how its extended use affected the user's ability to grab things without the tool. Imagine the damage we do to our ability to perceive our own bodies and perceive the space around us after hours tied to a computer keyboard and a screen 2 feet from our faces. Go further and try and see the confusion of a human brain after extended use of Twitter, IM, phone, Facebook, etc. How confused is a brain in truly perceiving the relationship between location, timezones and human behavior; especially as every one of these mediums cuts us off from the real interaction that we have evolved to trust and enjoy in human relationships.

Now go one step further. Give a person in an office a new software application to use to do their day to day work. More than just email, but for example a new tool for creating quotes for an insurance underwriter. If as a person you are absorbed in that application to do your job, you adapt to the application's shortcomings and come to appreciate its strengths (or perhaps unknowingly adapt to things you just happened to find useful).

I watched the joy on some user's faces just a few days ago when we showed them a demo of a new software solution. They have been doing copy and paste of information between systems for a long time. One tiny piece of our new solution has a built in search with their main system, and the ability to click a result to use that directly in a new piece of work. A simple click and the smiles were shining.

The function took 5 lines of Javascript and some configuration. And it will probably be the most loved piece of the overall application. The users will hopefully come to adapt to (and therefore not be able to live without) other pieces of the solution, though its important to see how such small details can make tools so much more an extension of a person and lead to improved acceptance and productivity.

A post from the Improving It blog

Download the podcast of this blog post

Will the EPA block regulation on Carbon reduction?

According to the WE campaign (we can solve the climate crisis), the Environmental Protection Agency (EPA) has the opportunity to facilitate, or to stand in the way of, future regulation of Carbon emissions. This could strongly affect Obama's capability to influence climate change through regulation:

The EPA recently released a finding that would allow the Obama administration to limit carbon pollution. But it’s not final until the public weighs in and the deadline to submit comments is this Tuesday.
http://www.wecansolveit.org/page/s/epacomments

Based on this very sparse information, I wanted to find out a little more. Here is the result of scouring the web to find what is actually going on. The most understandable information I could find was based on a public hearing led by Dina Kruger, the director of the Climate Change Division at the EPA:

[on the EPA] proposal that finds that greenhouse gas emissions endanger human health and welfare, and that greenhouse gas emissions from new motor vehicles cause and contribute to the climate change problem under the Clean Air Act.

The EPA is unable to make any rules until all stakeholders have a change to comment. Stakeholders include car makers, big-oil, lobbyists and one or two hundred million individual citizens. The rest of the several billion people in the world affected by the decisions of the EPA are not represented.

How can people put their opinions forward? Visit the EPA comments page on the WE website is one option. The EPA website also hides away how to comment directly. Go to the bottom of the page: Regulating Greenhouse Gas Emissions...

For those of you wanting a little more background, I found this brief history (dating from 1999, with all the action in the last 2 years) of Carbon legislation at the start of the Public Hearing document.

In 1999, EPA received a petition to regulate emissions of four greenhouse gases from new motor vehicles and engines, under Section 202(a) of the Clean Air Act. EPA denied this petition in 2003.

A lawsuit was filed, which resulted in the Supreme Court decision in Massachusetts v. EPA, in April 2007, where the court rejected EPA's reasons denying the petition, and found that greenhouse gases are air pollutants under the Clean Air Act.

The court stated that the EPA administrator must follow the statutory criteria of Section 202(a) and make a determination regarding the role of greenhouse gas emissions for motor vehicles in contributing to the climate change problem.

The options for this determination were either that greenhouse gas emissions from new motor vehicles do cause or contribute to air pollution that may reasonably be anticipated to endanger public health or welfare, that such emissions do not cause or contribute to a threat, or that the science is too uncertain to make a judgment.

In July 2008, in response to the Supreme Court's decision, EPA published an Advance Notice of Proposed Rule Making on Regulating Greenhouse Gases under the Clean Air Act. This ANPR made no determination regarding endangerment but rather requested comment on the implications of making an endangerment finding, and the underlying science.

On April 17th, 2009, after a thorough scientific review, Administrator Lisa Jackson signed the proposed finding that greenhouse gases contribute to air pollution that endangers the public health and welfare of current and future generations.

The proposed finding identifies six greenhouse gases that are reasonably anticipated to threaten public health and welfare. The proposal also finds that the combined emissions of carbon dioxide, methane, nitrous oxide, and hydrofluorocarbons from new motor vehicles and motor vehicle engines contribute to the atmospheric concentrations of these key greenhouse gases, and hence to the threat of climate change.

EPA's proposed finding does not include any proposed regulation. And before taking any additional steps to regulate greenhouse gases under the Clean Air Act, EPA would conduct appropriate rulemaking process and consider stakeholder input.

Massachusetts - a low lying state is threatened by Global Warming, with the chance that it will lose a large quantity of land and housing (currently inhabited by tens of thousands of people) if sea levels rise. I'm one of them! Now perhaps this proposed regulation is an opportunity for those people, with the population of the other east and west coast states, to get together and save their environment and their homes, and the lungs of everyone from more airbourne pollution.

A post from the Improving It blog

The missing link

I don't know when it happened, but the evolution of building software applications for business, especially those based on business processes and BPM, has led to a missing link. Not a sub-human creature of limited intelligence, although certainly a large gap in knowledge and capabilities inside the teams that define and develop solutions.

Leading a recent business process management project, I ran across this missing link several times. And it has led me to compare the profile of the software projects I was part of maybe ten years ago. Back in the good-ol'-days, software projects seemed to have a nice neat demarcation of roles: the business analyst worked with end-users and management to define the requirements that fed the current needs of the business and the perceived improvements; a software architect worked with the business analyst to translate these requirements into a software architecture of blocks, arrows, UML, and written specifications; finally the developers worked with the architect and (if they were senior and knew how to tie a tie) with the knowledgeable users to work out and eventually code software logic.

With BPM, the missing link has evolved through the pressure of vendors, industry analysts, and probably financial pressure in organizations wanting new software solutions cheaper. The roles have morphed as vendors and analysts tell companies that their business analysts can define and build workable processes without the help of their IT team (although see my post: Your 'Systems Group' is the reason you business teams (are) disintegrated if you want to see why I think that it wouldn't work even if your IT team was involved). The reality is that with the right tools, business analysts can build working processes, though they probably don't want to, because real (rather than just workable) business processes are hard, detailed, time consuming beasts.

So what is the profile of a team in the modern world? A senior business analyst has turned highly strategic (maybe because there is more caché in a hand-waving strategy role?), but still gets his or her hands dirty from time to time defining high level processes using a vague understanding of something BPMN-like. A more junior business analyst takes some of the concepts and tries to make a vague guess of how this maps to the details of the business. The great leveller of industry standards says that if you use BPMN you are sure to get a best practice result (I lie), and then fill in some spreadsheets for the other details you find out along the way that might just be useful. Now throw this information at a consulting firm's expert in your chosen BPM product, telling them that the analysis is complete and there is no room in the budget for further analysis, so just get building. Actually sounds very Dilbert-esqe.

What is happening? The software architect role is the missing link. He or she was carefully superseded by the enforced architecture of the BPM foundation the solution will be built on, forgeting that there was more to the role than blocks and arrows. The business analysts do not really know how to interact with software developers, since their contact has only been with senior strategy people they one day aspire to be, so the level of detail they are able (or willing) to collect is variable. But they try. The consultants are therefore forced to try and meet in the middle by wearing the hats of architect, process analyst, business rules analyst, process designer and software (at least customization and UI) developer. With top quality, highly experienced consultants, there is a good chance that they will fit the gap without a nervous breakdown. For less experienced consultants (or maybe worse, consultants highly experienced in traditional software lifecycles), the gap and constant flux in project requirements, definitions and uncertain rules can be highly jarring.

So, who wants to evolve to be stronger, better, faster, and take some of the traits of the extinct software architect? I don't know - and I'm open to offers from anyone who has seen this pattern in projects or believes that the architecture role is still alive and well. My guess is that the profile of projects I've been involved in has led to the customer not wanting to pay for the people I mentioned: process analysts and business rules analyst. Or maybe there still is a software architect role in BPM under a different name.

Either way, this trend of half-hearted, strategy rather than details-oriented business analysis, coupled with do-it-yourself process developers, seems to present a big risk to BPM projects. There are a limited number of BPM implementation experts out there, so if you want to implement a BPM solution, pick well!

I hope someone can help me with some solid experience, or tell me that consulting firms should stop giving way to clients and force them to pay for more time and resources. Or maybe someone will tell me to pick a different BPM tool that makes analysis, implementation and deployment so easy that the missing link was in fact a natural and necessary part of software evolution.

Comments welcome!

A post from the Improving It blog

Download the podcast of this blog post

Your 'Systems Group' is the reason you business teams (are) disintegrated

One of the big selling points of business process management (BPM) is the way it can provide order to the activities of disparate groups of workers so they can work better and more efficiently. To achieve this, you have to answer the big question 'how did groups that have to work together so closely end up so separated?'. In parts of a businesses that handle customer requests and new accounts (such as insurance underwriting or claims, banking account management, credit card disputes, telco and utilities customer service), it is typical to see separate systems forcing the business groups apart. When groups of users have to operate systems that don't work the same, don't share data and require swivel-chair integration, the way they work together as teams disintegrates.

It is the 'Systems Group' (or groups with other vague technical-ish names) that runs the line of business systems. And it is these owners that perpetuate the separation of business teams by failing to integrate their systems. So it seems obvious where to place the blame - the 'Systems Group'. But it is not their fault.

Repeated observation has shown me that the systems group are experts in what they do: they understand their systems better than anyone. They understand how the systems work, how to keep them working, and how to work around their faults. Because of this they are also often the designers of new 'applications' that fill a need of the business, in the form of Access databases or enormous Excel macros, that further separate and distinguish the roles of individual business users. And they are rarely experts in integration, largely due to the time and patience they must expend on nursing their current systems through another painful situation.

I have a recent example on a project I was leading - I had to teach various highly experienced technical people in the system group about XML, what it was, what it looked like, why it was different from EDI, and how a BPM system could use it to capture data from other systems (including that big Excel spreadsheet that is core to the business). XML is really not that new a concept or technology, but the guys had not had the opportunity to understand it.

With a limited knowledge of the available technologies, and even more limited time to burn, an organization's 'systems group' is not the team to apply to even basic integration tasks. If it was, the integration would have been done already.

So who should do targeted integration associated with BPM projects? That consulting team you have onsite already to build the new BPM solution may cost more than your internal team per hour, and may not be pure software developers, but it is likely that they understand integration mechanisms better than most. And if they represent a decent boutique firm, even if they can't build the integrations themselves they should have access to a team that can. Although it may cost a little more overall, the integration will get done, which is more than can be said for the situation many companies find themselves in currently.

The 'Systems Group' is the reason that your business teams (are) disintegrated. But it is not their fault. So help them improve, the same as you are trying to do with your business processes.

A post from the Improving It blog

Download the podcast of this blog post

Stop Persevering, Start Thinking

Consulting and software projects do funny things to incredibly smart people - they make them dumb and irrational. I've experienced it first hand (though I don't admit in public that I rate as incredibly smart).

So what's the deal? We've all used some variation of the phrase 'you can't see the wood for the trees'. That's what tough projects can do to people. They get so involved in the details of the project that they either don't notice that the project is starting to fall apart, or don't notice that it was never really together enough in the first place to fall apart. Then disaster strikes - the shit hits the fan - the customer starts ranting (more than before) and the incredibly smart people fall into the worst trap possible; they keep doing what they were doing before, just now at nights and weekends.

There are only three people or roles of people that I think can help prevent, or at least fix this when it happens:

1) The project manager or leader - the person who is falling into the trap and taking the project with them

2) The project manager's boss, mentor, or someone close to the project - preferably someone the leader trusts

3) The client - the guy who is being the biggest pain in the ass that there is right now

As a project manager, how do you prevent this? Well, I don't know that you can, but try following your own rules maybe and put in some checks or balances for your own personal behaviour, independent of the project.

• How many hours have you worked this week? Is it significantly greater than the average project you run?
• Have you started to find excuses why you can't do things differently in the project (the client will say no to everything you suggest, its just impossible, etc)?
• Have you made your team members miss personal events, weekends, etc?

As a project manager, when you really feel you can't take an hour off, do just that. In fact take two. One hour, complain and moan to yourself, go for a walk, do something that forces you to get away from the PC. The second hour, start brainstorming about how you can change the project; what is the stuff that is unnecessary, what can you do differently. This is brainstorming. Nothing is impossible. You can work out in the third hour (three hours, impossible!) what is going to be most effective at getting back on track with minimal impact to the value of the project.

As the person the leader trusts, have you seen this issue getting bigger? How can you help? I'm no counsellor in this stuff, and have always enrolled in courses of 'tough love'. Painful for everyone involved, unfortunately, though often gets the job done. Help the leader brainstorm, and visualize where the value in the project comes from, which is often not the individual details. Help them understand how they might sell some of the changes to the client.

Then there's the client. Why in the world would you want to put your project at risk, along with the potential risk to your business and credibility? So maybe its time to start compromising a little. Screwing the vendor or consultant out of every last bullet point rushed into the last draft of the contract or scope may just lead to a valuable, expert team becoming so overwhelmed that your aim of getting the perfect system may result in you getting nothing. Or worse still, a vendor that provides a system that looks great until its put into practice (cos those little features and design points you bullied them into were actually meaningless or of minimal value). Finally you could end up with a system that is functional, but nobody wants to go near it, in-house or external, because its tainted with bad-project vibe.

So, when you find that you just need to persevere a little more (beyond the 70 hours a week you already are), or need to shout at the vendor beyond the point that its fair sport, its possibly time to stop, put down your tools, and do the hardest thing of all. Start thinking about what you can change, and what you can ask the client or vendor to be changed, to get the project back on track.

A post from the Improving It blog

Download the podcast of this blog post

Custom software development is really better than complex configuration?

Another week in Mexico City, and nothing chaotic or remotely strange (by Mexico standards) happened. Life is heading back to its usual modus operandi. Offices have thermal imaging cameras at their entrances to catch suspected flu carriers, but traffic on the streets is back to its chaotic self and everyone is happy that this signifies a return to normality.

As for my current project with the large multinational insurance company, things are getting interesting. The team has entered an iterative 'construction and validation' series of development 'sprints'. The Case360 product is doing exactly what it should: providing a flexible platform for rapid development of process and document management solutions. Its nice to know that the messaging I put around it from a product management and marketing perspective while in the company was really true! I have to hope that Global 360 manage to keep some level of focus on the product in the future, since it really is a great technology.

Some interesting facets of using a product of this type, which allows production solutions to be configured without coding (beyond a little script here and there), are:

(a) how fast you can put skeleton solutions together that you refine over a series of iterations

(b) what a waste of time documenting and formally designing a solution can be

(c) customers start to think this is so easy they can do it themselves

The power of a software product that allows configuration of meaningful solutions, based on its templates and best-practices, also carries some risks. The major one is (c). A deep understanding of what the product offers, and how all the available pieces fit together in a usable and maintainable way is required by the consultants doing the work. Otherwise the solution becomes a series of disconnected and confusing components for the end user to navigate (how many of you remember Lotus Notes applications?). And some complex requirements, though possible to meet, require some serious thought, prototyping, rework, and occasionally coding, that can be hard for a customer to comprehend.

Its strange to me that customers are often willing to accept the opaque nature of custom software development if the whole solution is based on this. But if a solution is largely configuration and clever reuse of templates, anything complex is looked at with contempt, even though that the final solution is far more manageable than most custom software. There's no pleasing some people!

A post from the Improving It blog