Do we need ‘Jack-in-the-Box’ Software?

I just posted on my ‘Real World’ blog about IT project failures under the title ‘Perceptions are Reality’.

A long conversation with Michael Krigsman, who analyses reasons for IT project failures, brought back the old, old subject of ‘What does software do ‘Out Of The Box’? To me that is like asking: ‘Where does a car drive by itself right after you bought it?’

IT projects are not really about technology, effectiveness and efficiency. They are about perceptions and expectations, because how do business users choose sofware? Mostly by three criteria: 1) cute user interface, functional familiarity, and the lowest possible price. Is that wrong? No, that is perfectly fine if you are buying software ‘in-the-box’ or by its other popular name ‘shrink-wrapped’. Well, who would want software that was packaged by a psychiatrist (aka shrink)?

Surprise! Hidden costs with 'Out-of-the-Box' Software.

Ok, seriously again. The above criteria are ok for personal software but not ideal when we are talking about enterprise grade solutions.  Why? First, if it is not ONE individual making a choice but a large number of business users, apart from the lowest price how do you find the consensus among the users what ‘cute’ and ‘familliar’ actual means. The software options are radically reduced by trying to find the common denominator. But even cost is not as simple as it seems, because it is not just the cost of the product or the initial installation, but rather runtime cost in terms of adaptation. If there is a large group of business users they will want their own custom GUI and functionality. Eventually there will be a lot of customization going on.

Let’s also not forget the cost of integration. That is not just related to linking some backend data, but also  to integrating customer facing processes. Most software that is being bought out of the box for enterprise purposes doesn’t remain like that for very long, but sooner than later it starts to get modified. Many businesses have paid dearly for that. So total cost of ownership isn’t that easy to judge either. Sharepoint is such a standard software that works out-of-the-box, but does not really do much. As soon as you want to go beyond simple content sharing, you end up in complex software development and integration work. This backed by research that finds that Sharepoint users are very unhappy. That is typical ‘Jack-in-the Box’ software, where the true conseqences are hidden in the box under the smiley-face.

The author John Ruskin wrote: “There is hardly anything in the world that a man can not make a little worse and sell a little cheaper. It’s unwise to pay too much, but it’s also unwise to pay too little. When you pay too much, you lose a little money…..that is all. When you pay too little, you sometimes lose everything because the thing you bought was incapable of doing the thing it was bought to do.” It sounds as if he predicted Sharepoint …

I have had my share of experiences over the years despite the much smaller project sizes – not in functional scope but just manpower – of typcial Papyrus projects. Our software is simpler to implement, but we still need to close the organizational gaps between sales, installation, implementation and production through a unique PQA Project Qaulity Assurance team. After 22 years we yet have to have a project that failed or was cancelled, because our software or consultants could not deliver. The PQA main function is therefore not technical support, but to be a project coach, moderator and intermediary between business, customer IT and the various ISIS departments. Because we are not robots we encounter some of the people problems described by Michael Krigsman in the ‘Devils Triangle’ and he has not even mentioned the dreaded inhouse corporate politics and ‘change angst’ applicable to projects of any size. Therefore we avoid to work with system integrators (SI). SIs don’t like us because there is not enough manpower to be sold with our product and customers become fairly independent of the SI. That is not the integrator’s business model. Analysts on the other hand rate our lack of a huge partner network negatively, when we don’t like or need one.

In a current project, we are facing just that problem of perceptions described in my post. Being midway in the project, we are completely confident that we can deliver despite not everything being yet fully defined. IT is also confident that they made the right choice, but the business departments are frustrated that we are still working on infrastructure and architecture as foundations before we start putting up walls (aka defining GUIs). It seems that business has taken the empowering ‘Ease-of-Use’ proposition of our solution and simply applied it to the project itself. Well, a model-preserving approach is different, but how should they know when to expect what? They are jaded from years of experience of projects failing. Business simply translated ‘Ease-of-Use-Later’ to ‘Plug-and-Play-Now,’ when it means ‘we first have to install the plugs so you can play without IT in  future.’ Because there are just a few ISIS consultants and customer personnel involved – despite a rollout to 2000 users – those perceptions will be easier to solve, but a conscious effort has to be made to realign their expectations. Not to get less, but to clarify what they can get how and when. If not the project would fail.

The Papyrus Platform  is purely standard software that is not being customized for one individual customer and we do not even allow customizations or provide APIs. It uses a model-preserving application technology to avoid programming projects. We only allow integration by loosely coupled messaging interfaces to remain flexible, platform independent and upward compatible. Applications are defined and loaded into the platform as so called Framework Apps. Because the application is defined through object models and rules that are also fully documented in the repository, it remains  maintainable by non-programmers and to some extent even by business users. That is referred to as adaptation.

To make an application business user adaptible, it has to be defined in a certain way and the users have to be authorized to make those adaptations. Adaptation can happen at runtime ONCE only or it can be performed on templates for ALL future executions. Because the platform directly links to the business data and content, a data model, content structure and business organization model has to be defined to make the frameworks match the business needs. It is important that business users understand these concepts so that they do not have the wrong expectations of  standard ‘out-of-the-box’ software.

Yes, pereceptions are the reality for the individual. The IT department doesn’t know what is best for the user and  standardization for cost reasons will cause the ‘Ruskin effect’. While users might employ three strange criteria to choose solutions, we have to understand that this is all they are looking for! It is up to us to translate and amend those user needs to define a solution that will also fit the long-term requirements of the business. Thats what we have delivered with the Papyrus Platform: a standard ‘out-of-the-box’ solution that with very little effort can provide whatever business users need. And that statement alone can create a variety of unwanted expectations and perceptions … 😉


Papyrus Project and Services Planning

Most Papyrus Platform projects go quite smoothly and deliver powerful functionality without the need for a complex development project. The broad functionality of the Papyrus Platform enables larger and more consolidated applications, with the consequence that some of the projects in large corporations are a struggle despite the advantage that there is no Java or other programming necessary and that the number of involved people is quite small.

Once Papyrus gets chosen as the solution it means that business users saw something in the demo that they liked in terms of frontend and IT saw the functionality required in terms of technology. Neither business nor IT seems to accept that there is a need to use their specific business data model and interfaces, create the role/policy setup for authorization, define the building block objects, setup the administration workflows, define and test the backend data interfaces (despite XML, it is always the last thing provided for testing by IT), interface the document creation with printing and archiving and some more linkage here and there. Once that has happened the business workflows have to be defined. We always recommend to use the UTA to train them, but often someone decides that the workflows have to be rigidly defined so that they can be audited in advance. So suddenly someone (usually a third party) sits down and does lengthy process analysis.

All the while we are typically training and supporting third-parties who have never seen the product before because they were chosen as the cheapest manpower option. Project management takes a lot of time as well with daily meetings that take away time from implementation. Project planning and timing hardly ever happens according to business needs and IT capabilities, but influenced by company-political turfwars and budget constraints. The later we are in the project, the more management gets involved who know nothing about it.

Then the document templates and components have to be defined by the business users. Instead focusing on that business users come forward with the first change requests to the user interface – that they originally liked. Not too difficult, but it is an uphill battle against time. New requirements appear daily and are made no-go critera without changing the productive date. The planned time for testing gets shorter and shorter and no one takes the time to define proper testcases and acceptance criteria. No people were trained to run production but the go-live date is adhered too. Obviously there are issues and therefore each and every situation is reported to ISIS as a BUG to get support for free. Often there are issues with other applications that we are connected too or network or server issues and these are ALL ‘Papyrus problems’.

Does that sound familiar? Yes, it can get very frustrating! Depsite all of that the team at ISIS Payprus has ALWAYS delivered. The projects that were not taken productive failed after the Papyrus implementation was complete. Look, I am not blaming anyone. I am just stating the facts. I cannot laugh about the Dilbert comics, because they describe corporate ignorance too accurately. But enough of black humor. Let’s look forward on how to avoid these situations. It is really not that difficult!

What can we and the business users at our customers do to speed up projects?

  1. Create a milestone plan of implementation phases where each states the functional goal or achievement.
  2. Project phases must not have a rigid completion date and be able to overlap with the next phase.
  3. Utilize a business architecture team, one or more implementation/test team(s) and analysis/tuning team(s).
  4. Business architecture should be inhouse IT, analysis/tuning from business and IT, implementation can be external.
  5. Start with a simple phase that can produce benefits quickly and that allows gradual growth and expansion.
  6. Papyrus is LEAN technology by design, so it makes sense to remain AGILE (expand iteratively) in approach.
  7. Utilize teams in a mode that allows overlap of analysis, implementation, testing and tuning for phases.
  8. ALWAYS COMPLETE the first phase without add-ons, but add new features to later phases.

Overall the project approach would look like this and enable the business users to get early results and be closely involved in tuning the application to the optimal functionality in the later phases.