10 Keys to a Successful Portal Project
Before you look at the factors that can lead to success, let me attempt to define it. A little research into project success rates shows that there have been no unbiased statistics for the last decade. There are plenty that claim to be, but a little digging always resulted in a major contribution to the numbers being from a company that profits from helping you be successful. There is nothing wrong with these companies promoting themselves in this manner; it only leaves the reliability of the numbers in question. So, I will leave statistics out of the definition.
The numbers on success vary widely depending on what factors are considered to define success. Was the project within budget? Were the stakeholders satisfied? Did the project complete on time? Oddly, the one criterion not found was user satisfaction. Does this mean that if it was within budget, on time, and stakeholders (rarely users) were satisfied, but no one used the software, it was still a success?
For the purpose of this article, I will define success solely as return on investment. ROI can be achieved by increased profits and operational savings, either inclusively or exclusively. My experience has been that the only sure way to achieve a positive ROI on a portal project is for users to use the portal willingly. Time and expense are definitely necessary factors, too, and are considered in each of these ten keys.
1. Plan Big
Someone once said (and has been plagiarized on this often) that "the only limitations to achieving success are time and resources." There are some projects that are planned by starting with the limitations. Other projects are planned ignoring them entirely. You shouldn't need a consultant to tell you that any extreme is going to lead to at least disappointment if not total failure. And you shouldn't believe anyone who tells you that they have the absolutely perfect approach. What is proposed here is to start without limitations to avoid having them, well, limit you.
The initial planning should be very pie-in-the-sky, and preferably facilitated by someone who can both bring out the creativity of the planning group, remind them gently that they may not get all that they can imagine, and artfully dodge the inevitable requests for practical limitations before it is time to apply them, which is after all desirable attributes have been expressed. There are two ways to know that your group has completed expressing their complete list of possibilities. The first way is when the last dozen ideas are considered impractical or useless by the majority of the group. The second is when reality re-enters the planning session and you have run out of time. And, you have to run out time to avoid the dangers of analysis paralysis.
2. Deliver Small
With unlimited time and resources, the honest among us will admit that they would never deliver anything. Still, it is incredibly common for projects to attempt to "fill a five pound bag with ten pounds" as one project manager often described his job. If a portal were to actually deliver all of the features listed in the unlimited planning session, it would either do many things so poorly that no one would ever want to use it, or take over the planet. The only sites that come close to taking over the planet started really simple, so you can safely assume that smaller is better.
With your list of desirables as long as possible, it is time to once again gently remind the team that limitations are something we all live with. Many projects that start off with the pie-in-the-sky feature approach narrow their choices by presenting them to the technical teams to review. This can occasionally work out well if the technical team has built many portals for the same stakeholders and users. However, even these dream teams can benefit from another approach to narrowing the scope to something that can be delivered successfully (remembering that your definition of success is ROI). That approach is to rank the full list.
Hopefully, the want list is large enough where the first reaction may be "that will take forever." It doesn't have to, if you break it down into stages. The first stage is to divide the features into three groups of desirability: high, medium, and low. The easiest way I have seen this done is to put all of the features on sticky notes, and then have each member of the team as a group mark the notes with their ranking. Total the votes and you now have three lists. Put the low list away, and then rank the remaining two. Usually, during this final ranking, some of the highs and mediums will get dropped to a low. The result is a prioritized list of features the team agrees will be useful.
3. Choose the Right Product
Although I would be happy to provide one definitive product in this section that will make your project a success, that would be the one sure way to achieve the opposite result in many cases.
There are many (though fewer than as little as five years ago) portal products. Some are specialized for specific portal types, such as collaboration or ecommerce. Others are general purpose. Your prioritized requirements will narrow the list from all portal products to some smaller amount.
Portal products also are differentiated based on programming language. This may or may not be a major factor in choosing, depending on your training budget and timeline. Do keep in mind that, if your technical team is highly skilled in a particular language, the savings in training should be carefully weighed against functionality and features that meet your requirements. If a large majority of your requirements can be filled using out-of-the-box features from a product in a language where your team needs training, the product advantages may outweigh the training costs.
Another frequent decision point for portal products is vendor support. Even though vendor support may give some people a great sense of security, if your technical team is comfortable working with open source products they should not be ruled out. The opposite consideration should also be made, in that if the out-of-the-box features will need to be customized for your needs, it should be determined carefully if this can best be done with an FOSS or COTS portal application.
Finally, you may also consider something totally custom. This is seldom the best choice, but seldom does not mean never. I clearly recall a series of several portals built for one company that someone later said could have been done for a much lower cost from scratch. At the time, I agreed. A year later, many of these portal were combined together, which would have been an enormous undertaking if they had been based on a custom platform rather than a commercial product that made it a fairly straightforward project.
4. Front to Back
The most successful portal projects I have worked on started with a "clickable demo." If you have already determined your portal platform, by all means build it the demo within the platform. Otherwise, you should still be able to reuse much of your demo HTML in a final product.
Although I mentioned in the introduction to this article that reliable statistics were difficult to locate, one factor was fairly consistent. A key risk factor of web-based projects is changing requirements. From experience, requirements most often change when a great deal of effort has been put forth to deliver and then the stakeholders look at the results and change their mind. This could be because the requirements weren't clear, but it is just as often from the realized requirements leading to new understandings or needs.
Even though it is great to be in a room with interested and creative people planning what they want, there is no substitute for being able to actually "see and touch" something that represents what looks good on paper. Once a clickable demo is available, stakeholders can see what their vision will look like. This is also an excellent time to conduct usability tests with actual users, bringing out key success criteria under scrutiny before making a huge investment. Good HTML work takes talent, but it can be changed much faster than a completed end-to-end application where it is discovered that the feature is not what the user wanted or needs some major change before it will be something that the user will want to use.