10 Keys to a Successful Portal Project, Page 2
5. Back to Front
Okay, so during the Plan Big stage I said that it was important to not discuss technical limitations until the right time. Now is the right time.
This key stage in a successful project can (and usually should) be run in parallel with building the clickable demo. If a feature is identified as impractical prior to presenting it with a look and feel, it will save a lot of frustration to all by removing it from the demo before someone sees it and thinks it's cool. Although the cool factor can lead to success, with your key success criteria as ROI, cool may be a limitation to success.
Taking the list that the requirements team prioritized (but with the prioritization removed to avoid prejudice), it is now time for the technical team to provide their ratings. Even though the technical team may have their own (correct or not) notions of what is useful, they must put that aside and solely rate each feature with a risk and an effort level, again using the High, Medium, Low scale. Features that have both a High rating in both should then be compared with the desirability ratings, dropping those that are low on the wish list.
The remainder of the list should then be reviewed between both the requirements and technical teams to finalize what can be delivered with the best expectation of success. It is highly recommended that this negotiation be arbitrated by an unbiased party that also has a good understanding of both the business needs and technical considerations. In all honesty, this is probably the most difficult success factor to achieve, which also makes it very high on the worthwhile scale.
6. Generalists and Specialists
Project teams are generally fluid. They change to some degree with each project. For a portal project, it is important to have a good mix of specialists and generalists. Generalists are necessary to keep an eye on the big picture. These are the people who will catch the discrepancies that occur when one group finds a solution to one problem and adopts the "if you have a hammer in your hand, everything resembles a nail" mindset. They can also see where different requirements or approaches are either mutually exclusive or present a much higher effort/risk value when combined than they do separately.
The need for specialists is a matter of practicality. There are fewer generalists than specialists, and far fewer generalists that are highly skilled in the specifics of more than a few of disciplines they have knowledge of. A good generalist knows when they need more details from a specialist, and a good specialist has an intuition when they need input from a generalist, even if the input is only for the generalist to participate in a discussion across specialists to achieve the best approach.
For the areas where a generalist is highly skilled in the specifics of role or technology, the highest chance for success is to have a specialist on the team who can handle the job as well. This is because the generalist will often be involved in "fire fighting" some aspect of the project using only one of their skills, leaving gaps in the project progression that will need to be filled by others.
There are many specialists that are multi-disciplined, yet still not generalists, and many generalists that have no particular specialty. The key is to have one generalist and one specialist for each role. This isn't to say that there must be two people per role per project, only that the team should be comprise of members who can support each other. One example would be a project that requires ten roles. A single generalist may handle the generalist part of the team, and five specialists each with two specialties. Any combination is fine, so long as there is cross support for each role.
7. Maintenance Planning
All portals require maintenance. What is surprising is how seldom the maintenance requirements are identified before production. As mentioned earlier, project teams tend to be fluid, yet so many portal projects get all the way to production with the unstated assumption that the development team will be available for maintenance. A more realistic plan is to identify members of the development team who will transition to the maintenance team immediately upon release. Depending on the size of the project, their time post production may be divided between maintenance and new development. This is actually highly desirable because it provides a good way for those entrusted with maintenance to keep informed on what future features they will be responsible for.
Another approach is to have a completely separate maintenance team. This is often practical for very large portals (though, as mentioned occasionally in earlier sections, a very large portal for a first release is usually not conducive to success). When the maintenance team is separate from the development team, it is important that the development team have thorough documentation. The maintenance team must be assembled far enough in advance of release so that they can review the documentation with the development team for gap analysis. It is also advantageous for this type of maintenance team to participate in QA, to give them early exposure to issues that may occur in production.
8. Have a Growth Strategy
Just as death and taxes are considered inevitable (though some of us still hold out hope for that to change) a portal that is successful on release must evolve to continue being successful. If the success key of Deliver Small is followed, you should have a list of desires yet to be fulfilled. Once the portal is in the hands of users, that list should evolve as well, because users are your best source for ideas on how to improve the success of your portal.
A growth strategy for a portal is another one of those areas (like the choice of portal products) where only suggestions can be given, rather than absolutes. Identifying members of the initial team to fill permanent roles related to the portal is one strategic approach. Another approach is to obtain a budget for expansion, even if that budget must be justified by requirements that were postponed while knowing those may not be the requirements implemented in the next iteration.
The UI design should take growth into account. The navigation needs to be flexible so that it can be expanded without major changes. There are few things more frustrating to a user to have new features introduced that make it difficult to locate the features they were already using.
The system architecture should anticipate growth without leading to a large effort to fulfill future needs now. Taking a pluggable approach to component integration is the best way to pave the way for growth without spending a large amount of time and effort building something to support functionality that may later be abandoned for something else.
9. Build POCs Before Committing to Delivery
Remember the list of risks and effort? It is pretty common that this list will be a bit more optimistic than it should be. Developers by nature are optimistic, which is why most of them work long hours. One way to mitigate this optimism (which is a good thing and why the technology continues to grow in leaps and bounds) is to define anything that your team hasn't personally done as medium to high risk. If it is something that is well documented and examples are readily available, it can be rated medium; otherwise, it should be considered high risk.