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 ;)
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.
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 ;-))
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.
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…
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.
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:
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:
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