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.



Banana Applications?

Based on feedback I need to make something clear first: We at ISIS Papyrus NEVER provide custom code for a single customer. We deliver a STANDARD product only and all customers on a same release have the same functionality. But yes, we do expand our product functionality on request that becomes a standard feature of the next software release and is fully included in our QA and 2-3 month of regression testing.

Despite that, we recently had once again the discussion with a client as to why the ‘Papyrus Solution’ he has acquired does not work the way he needs it to work. He complained that there were lots of bugs that had to be fixed and that so much testing had to happen at the customer site. Previously people had used the joke that Papyrus was ‘banana software’ that ripened at the customer. As a matter of fact it is not the Papyrus system that has to ripen at the customer. It is the application that has to be defined the way the business needs it. And that is just the way it should be!

Why do people complain? Is the software really that unstable that it requires continuous bug-fixes at the customer site? Absolutely not. There are three situations in which customer management (usually people not involved in the project) make such comments.

First, there could be a real bug in the software. We are not gods who can create flawless code and we also can not test each and every possibility Papyrus can be used for. In 90 per cent of cases such a malfunction can be bypassed. There are in fact very few crashes in our software which has to do with the 9 compilers that it usually runs through. While GUI crashes are the most annoying to business users and impact opinion the worst, they are the least important because it is a different executable than the node kernel and does not make the system unstable.

Second, the customer makes new functionality a ‘critical requirement’ during a project. Either we expand our software or else … That means that our normal three month quality cycle can not be performed. This problem is the worst once again in Desktop and Client. It was the main reason for us to develop Papyrus EYE, so that we do not have to expand our solution for a specific project but can simply define the GUI much like we do documents and processes.

THIRD AND FOREMOST, the Papyrus Platform always runs an application that is custom-defined for the business. Yes, they build on existing frameworks of classes and rules, but the beauty of it is the managed and controllable customization concept. BUT, it still is a custom application and that is the way it should be. In many cases that custom definition was not performed by ISIS consultants but by a partner or an external consultant. When a customer now calls and says that the ‘Papyrus System’ is unstable he refers in 99.9 percent to his APPLICATION that in most cases was not defined by ISIS. So in the worst case he has a ‘BANANA APPLICATION’ that was coded by consultants in hit-and-run style and never properly tested.

Do not get me wrong. I am not trying to shift the blame here or not take responsibility. We have always made those applications work and rarely had to fix crashes to do so. The Papyrus Platform enables fast application definition but that does not mean that they can not be wrong or do not have to be tested. They need less testing and can be fixed faster, but it needs a normal project management approach. Hardly ever does a customer allow for enough time for testing. As the project is the delayed, the project deadline is not. So the testing timeslot gets shorter and shorter. That applies mostly to the adapter interfaces, because usually the Papyrus Framework is long done before the backend application can deliver test data. Are you aware that is the main reason that techies like XML files? Because it is easier to create test data by hand in XML than in some other binary format.

In a project a year ago I had to visit the customer site to calm such waves. The application had been created by a non-ISIS consultant who had no time to come back. It had worked fine, but then the customer decided to replicate it to three production nodes with linked workflow queues. It actually worked this way, but the defined queue rules were interfering with each other. Once we figured that out it was easily solved. The main problem was that the production manager would just log the bugs but had no interest to support the debugging. So they had a huge amount of problem tickets from ONE bug. Also a way to create IT jobs.

So I have to ask project managers, production managers and CIO’s to understand that there are systems and applications. If an application does not work on a platform like Papyrus it is mostly the defined application that has to be changed. If your document in MS-Word does not have the right text you don’t call Microsoft. You simply correct it. You can do the same with the Papyrus Platform because it is not complex Java programming and the changes are perfectly managed in the WebRepository.