In Part 7 of the series, I wrote about the importance of using an experienced core team. However, every single resource on your project will not be a senior resource with years of relevant experience and that is the focus of this post. If you do throw resources into the fire and expect them to be fully productive without any ramp up time you are not only setting up individuals for failure, you are also doing it for your project..
Who Does this Include?
There are various roles that this article can apply to but I am going to focus on 3 roles that are applicable to WebSphere Portal implementations:
- Visual Designer
- Portal Developer
- Portal Administrator
Visual Designer
Portal user interfaces are implemented through themes and skins. These are not terribly complex and offer great flexibility for creating rich customized user interfaces in WebSphere portal. What will get you into trouble however is if you have a visual designer who simply creates a user interface without understanding portal and throws it over the wall to developers to implement. Themes and skins are very flexible; however, there are some limitations and if a visual designer does not understand what a portal is and some of the basics such as portlets, themes, skins, pages, labels, etc, they will inevitably design something which either cannot be implemented in portal, will take a long time or require extensive customization. This however does not mean a designer needs to attend a week long class. What is sufficient is for them to work with the portal architect in order to understand “portal 101” and to have various checkpoints to make sure that the creative design is not stepping outside of portal’s bounds while at the same time leveraging as much portal capability as possible. The goal is not for the portal architect to dictate and influence the design but rather to validate it.
Portal Developer
Portal developers will undoubtedly do a large share of the work and the development phase is often the most time consuming phase of a portal project. Keeping this cycle as short as possible is a big key to getting to production quickly. If you have to spend the first two weeks of development having developers install Rational Applicaiton Developer and portal in their local environments, connecting to source control, opening request tickets for access, etc, you are essentially wasting valuable devleopment time. Taking these activities on early so when development iterations start, developers can develop and have the access they need is critical. Furthermore, when you have less experienced it gives them more time to get immersed in the project in the technology.
One other thing I always find very valuable to immersing new developers in how to develop in portal is to assign them smaller and less complicated scope items at first rather than a brand new portlet. For example, take one of your model portlets which you consider to be very well written and one that implements the best practices, standards and guidelines your organization wishes to follow and have a newer developer implement small extensions to that portlet. This way, they will be learning with an approach the way you want to do it instead of starting from scratch, struggling, and ultimately developing something inconsistent with your standards.
Portal Administrator
Now here is the role that can bring your portal project to a halt if they do not know portal. I’ve seen several customers take their rock star WebSphere administrators and say you need to install unit, test, stage, and production in a couple of weeks and well, you can guess the results… inconsistently installed environments, missed deadlines, and inability to support the development team during crunch time.. There is no doubt they have the skills and while a base portal installation is quite simple, once you start clustering, implementing SSO, and implementing custom configurations, it gets considerably more complex and you have to be very meticulous so no steps are missed and all environments are consistent. There are a few things you hopefully can do here to help. Having the environments available at least 2 weeks before you think anyone is even going to need them is imperative so just plan for it. To do this, you need to give your WebSphere Admin the time they need to properly plan the environments and not distract them with other activities such as production support. Additionally if at all possible, provide your newer admins with mentoring assistance from an experienced portal administrator. This will undoubtedly help get them up to speed.
The Results
Now that you have groomed and grew your resources throughout the project what you have now built is an expanded experienced core team well positioned to deliver portal releases quicker and more often.