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.
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.
There have been many projects where the risk was rated too low because product documentation stated that a feature was supported, where it was later discovered that there is a large gap between “supported” and “easily implemented.” If ROI is as highly user driven as you are assuming (well, I am, at least), there are few things more user-vicious than to promise a feature and not provide it.
Any item that is high risk should given a practical test, or developed as a fully functional proof-of-concept before committing to delivering it. The POC will provide a better understanding of both risk and effort, and improve ROI because a feature that fails to work as expected requires extra work on the part of QA staff, development staff, and analysts. The saying “there is never enough time to do it right but always enough time to fix it” leaves out one important factor: It costs more to fix it than to do it right.
10. Know What to Reuse or Replace
Even though almost all developers tend to be optimistic, they are pretty divided on their preference of either reusing what already exists or building everything new. They also tend to follow this preference single-mindedly. Because many development managers were once developers, their tendencies often become the culture. This is not always a bad thing, because such cultures often evolve to where they can deliver consistently with their chosen preference. If the delivery is not consistent, it is important to develop an approach for evaluating existing assets for each project and make a dispassionate decision whether reuse or replacement will server the project best. Although the development team must be part of this decision process, it is best to have it facilitated by someone outside the team, preferably someone who doesn’t have their own tendencies in this area.
One common theme of all ten keys to success is that the user’s needs must come first. If you want the user to need something for your profit or savings, it must be provided in a way that gives the user a benefit.
Creativity is also important to a successful portal project. It should be fostered from the earliest stages of the project and encouraged at each stage. Creativity is not limited to coming up with features to deliver, it can (and should) also be applied to making compromises between business needs, technical considerations, and usability.
Finally, more than one key to success is clearly a matter of finding what works for your particular project rather than a panacea path to portal project perfection. This also means that actively looking for more than ten keys is the eleventh key to success.
About the Author
Scott Nelson is a Senior Principal Consultant with well over 10 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. He also blogs all of the funny emails forwarded to him at Frequently Unasked Questions.