• Internet
• 29.01.2019
• EN

Manuel Schnitger: Evil eye

written by Manuel Schnitger, 11. November 2011
 

This article describes some general ideas and approaches in regards to project planning  and avoiding unexpected situations. Most of the things I write about are probably not very new or supprisingly but I find it useful to write them down.

So if you don’t want to see evil eyes looking into your direction … read this article ;)
 

Project planning – Ask the community!!!

If you want to avoid the “evil eye”  it’s helpful to have a good concept. But how do you know if your concept is the right one and meets all requirements of the current project. Well, if the functional requirements of a new project already exists it makes -at least from my point of view- absolutely sense to ask the community. So if there are any things (requirements) where you think: “I don’t know how to implement these things.” or “I have an idea how to implement this functionality but I’m not sure if my approach is the best one.”… then asking the community is probably a good idea. The reason why I think asking the community is a good idea is because I saw so much great things in the past months/years.

• There are lots of users who really post high quality information in their blogs. (See my (totally uncomplete) blogroll)
• Within the forum at SolutionExchange members of the community give very good advice and for each and every topic there is an expert available who is happy to share his knowledge with you.

At the end of the day, asking the community (probably) results in better projects, satisfied editors & authors, and less frustration. (Hint: As discussion about the best possible solution can take some time it makes sense to ask as early as possible ;-))
 

Out-of-the-box vs. custom scripts

If you start thinking about using RQL, jQuery or any other script or any other kind of customization in order to create some new functionality, then you should spend a few minutes with thinking about the pros and cons of those approaches.

Pros:

• The Usability can be enhanced in some situations where this seems to be necessary.
• Specific steps which normally would be done manually can be combined in a plugin or user defined job and can save a big amout of time.
• If it’s likely that the system/project is used by users who need an even easier frontend than the one that is available (because they don’t use the project too often), then scripted solutions can be helpful.

Cons:

• The normal frontend of the Management Server with the out of the box functionality is very good and normally “scripted enhancements” are not really necessary.
• Scripted implementations are not supported by the Open Text support team.
• If  there is not a proper documentation it might be hard/impossible/expensive to debug the implementation if necessary.
• It’s not for sure that implementation runs after an update of the Management Server software.

What I don’t want to express is, that customized solutions are generally an issue. If you have a look at the articles RQL in a nutshell (Part II, Part III) then you know that I love RQL and customized solutions  But sometimes I see projects…

• where customized things are implemented and a completely new user interface that differs from the normal one is introduced. (Is that really necessary?)
• where hardcoded paths to the dialogues of the Management Server are within the temlate code (What happens, if the paths or names of the dialogues change? And who will correct the links? And how often will this happen?)
• where a lot of infoelements, RQL and other functionality is used in order to display information that can be retrieved within the normal frontend (Is it necessary to display this information on each and every page? Did someone ask the editors, if they really need this information? Is it too time consuming to use the context menu?)

So the conclusion is: Customize your project whereever it is necessary, but don’t implement things because they just look cool

Hint: The few lines above are more pointing to customization of the frontend of the Management Server. Of course there are lots of other customization/plugins (e.g.: Image Gallery Creators, AutoFileName, CopyElement, etc.) which are extremely helpful and those things are not the focus of the above paragraph.
 

Risk Impact Matrix – Start early, start smart

An approach that can result into trouble can be to implement things in the order they are mentioned in the concept. If all things can be implemented without any problems then this “normal” approach is absolutely ok. But when specific tasks could possibly lead into time consuming debugging or testing scenarios, then it is a good idea to identfy those tasks and try to find a solution earlier than they appear in the concept.

So what we do is:

• We split up the project into different tasks (e.g.: “Create LDAP connection”) and assign a number to each task.
• For each task we ask us two questions: How likely is it, that this task goes awry and what would be the impact?
• After that we can enter the number of the task into the corresponding field within the matrix.

Q: Is there are clear rule that tells me how to define the likelyhood and the impact?
A: No. Just compare the task with the other tasks in the project or  listen to your gut response.

Figure 1: Risk-Impact-Matrix

Each task that is entered in one of the red fields means:”Don’t wait till the task is mentioned in concept. Act soon!”

The results of the things mentioned above could then be:

• Create a proof of concept in order to see if things work as planned.
• Ask the community for help.
• Try to put the specific task in a later phase of the project in order to have more time to find a proper solution.
• Ask the official support team.
• Involve the global services team of Open Text.
   

Quantity structure

Often things (functions, plugins, etc.) work very well and are very convincing when the number of objects (pages, users, groups, images) is not that high. But sometimes I saw projects or to be more precise solutions which worked perfectly in the project when it has been developed. But with a growing number of “things” it became clear that the solution wasn’t really designed for this amount of objects. So in order to avoid confusing structures, poor performance or a bad user experience, just think how a specific solution would work within a real-life scenario.

Hint: In order to create such a real-life scenario, you can simply use an RQL plugin that “pumps up” the project.  With such a plugin you can easily create thousands of pages within short time and see how your solution handles this situation.

If you should have more/other ideas how to avoid the “evil eye” then let me know and I’ll write a second part of this article.

Source: Evil eye

© copyright 2011 by Manuel Schnitger