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.

phased-milestones

Analysis, Fact and Prediction

I am sitting here sipping my morning coffee in the Tradewinds Resort in St. Pete Beach, in Tampa Bay, Florida. I flew in to attend the XPLOR conference from snowed-in Boston last night where I had another fairly tiring meeting with Forrester Research.

By chance I had arrived when Forrester’s Andrew Bartels just held a presentation on the economic outlook. Following current industry estimates he believes that the IT industry will start to see growth again from the 4th quarter 2009. Well, could be. If nothing happens in between. I found more interesting that he proposes that we are at the beginning of new cycle of IT spending for applications that are ‘smart‘. I am in principle agreement because we started that with our User-Trained Agent, but the term ‘smart’ has been so oversold that it will be hard to use it that way. He then suggested that the ‘smartness’ would have to be focused on certain market verticals and here my question was why? If the software was smart enough it would adapt to the needs of the vertical. He said, it would not be that smart. But after a little discussion I came to agree that some knowledge acquired by our User-Trained Agent could be valuable within the vertical – if the business is willing to share it. Another subject to be clarified in the near future …

I have said previously that I prefer Forrester over many other analysts because they are attentive. I have met with Craig LeClair and Sheri McLeish to discuss an upcoming report on customer communications or CCM, which is an expansion of the previous DOM Document Output Management field. Craig and Sheri are very knowledgable in this arena and it was still extremely difficult to get the functionality of the immense spectrum of Papyrus across. I was my second visit because during the first one hour session there was not enough time to discuss the Papyrus Interactive and On-Demand functions. It will be very interesting to see what comes of this resarch. As we are covered by Forrester for the first time (because I had not bothered before) my expectations are low. I cannot imagine that they will let us leapfrog the ‘established’ players on our first participation no matter how good we are.

A couple of discussion points are worth sharing with you. First, Craig did say that he considers the number of installs in the US as a measure of product quality. So now you know why you will find the large players up front and it is not because they have the better product. When analysts consider market share and revenue, they rate advertizing budgets and sales tactics but not how good the product is for the user!

One point of poor rating was my sceptic stance towards the use of ‘standard’ XML. There is no reason why native use of XSL-FO would ensure higher quality and accuracy of processing than conversion to an internal format. According to Information Theory the functionality of a language such as XML is not intrinsic but defined in how the tag structure is interpreted and executed in the code. There is no difference between a conversion to internal formats or mapping one XML to another. As the meaning of XML tags is never fully defined (try to look up and understand XSL-FO descriptions!) the quality of interpretation is always limited. This is proven by the available open source XSL processors which are not compatible in function. Therefore all software vendors have their own special versions. Conditional processing, resource management, font support, multiple codepage support and external SVG charts make the use of XSL-FO a propietary affair.

There is one acceptable XML benefit that is obvious, when you are transforming into a web document. But for any serious business application you have to create an electronic original (sometimes even digitally signed) that you need to present and transmit. It is a grave mistake to accept the limitations of XML for transactional business documents for this tiny benefit. Additionally the presentation of XSL into web browsers is not standardized either. An enterprise user only gets controllable document quality by presenting to either image, AFP or PDF.

Another point Craig made was that only Adobe gets the highest mark on PDF support. I see. Thank you for admitting that PDF is still a proprietary format. Why do we not get the highest mark for being best in supporting the Papyrus Repository?

Craig also took issue with our Papyrus EYE user interface, saying the FLEX is better because there are more developers for FLEX on the market. We do not need programmers with EYE but FLEX is better because there are more programmers for it? 

George Colony, Forresters President, focuses on the other hand on a Business Architecture as the basis for tomorrows applications. Yup, that is the way to go and that’s what we supply with the UML2 models in our Papyrus WebRepository. I am bracing myself against the disappointment of Forrester rating us poorly because they can’t understand the power of our repository that are also valid for a seemingly simple communications application. But then all formatting vendors claim to have a repository, because they just call it that. AIA ITP has a directory with a couple of configuration files and a few tables with text and letter structures and they call that repository??? Get real, please.