So I’ve been thinking about what makes projects succeed of fail. I’ve seen the results of a number of failures and while you can point to a lot of points, here are some pretty common ones. I put them in no particular order:
1. Poor Total Technology choice
In other words, they may have chosen a really good portal but then put very little or no thought into content management, search, metadata, security, development standards, etc. I review one client who had chosen three very good products in the Portal, CM, and Search fields but because CM already had search, they ended up going through extra hoops and processing cycles to make it work. This same client had chosen to use their own MVC rather than an existing and constantly improving one like Struts, JSF, or Spring MVC.
A different client chose one portal project for it’s cool web content management module and then used another product for the presentation layer. They actually made good choices for the individual technologies but a very poor choice in overall architecture. It was poor because we had to go through extra cycle and take more time to get to the result demanded by the business.
2. Lack of Direction
You will find that this is not unique to the portal and collaboration world. Technology is cool. It really is. People like me and other technologists could dwell all day in it but we don’t pay the bills. The business pays the bills. We need to work with business to set direction. If you haven’t set direction from a business perspective then bad things happen. Let me give you a story that occurred about 6 years ago so it’s ok to admit a mistake……
We were developing an employee portal and hosted a set of workshops with our client to determine the functionality we would launch in phase one. We met with the various constituencies and determined that the most important piece of functionality to put on the portal was an existing classified application that the 5,000 or so employees used to buy and sell personal items. You can imagine the reaction the business leaders gave when they saw that……..and they were right to question the result.
Now, we meet with business leaders first and ask about where their business is going, what factors are the most important and how we can align this initiative to their needs. That hasn’t happened since although we still get some department managers telling us how important it is to post Valentines Day images on Valentines Day.
3. No teamwork between technical resources and the business
We know it’s going to be a rough project when we start and are told that one IT person will be our liaison for everything. We are not supposed to actually talk to business users. That guarantees a couple things:
- Business users don’t buy into the project because they never get the chance to see anything happening.
- It pretty much guarantees that we won’t understand the solution so whatever we deliver will fail.
- The business will feel the need to inject their thoughts and needs into the process the first time they see it. That may well be in User Acceptance Testing (UAT). We all know that new or changed requirements in UAT means missed dates and blown budgets.
4. Lack of focus on the user
If I had a dime for every time a “chief” somewhere said, “Let me put on my user hat to define the requirements and UI.” That kind of feedback inevitably results in a site that doesn’t meet the needs of your end users. The head of Corporate Communications doesn’t really know what employees want. The head of Marketing doesn’t really understand what customers want to do on the site without asking.
You should ask what they want. You should solicit objective feedback. You should test out what you think with the end user. We did that once with a fairly complex application and discovered out SME had forgotten several key fields and one process. We discovered that when we were still in pencil and page stage. It was a lot cheaper to fix it then than when we threw it over for testing.
5. Poor project management
I think this is important enough that I created an entire presentation around it and presented it at the Portal Excellence Conference (blogged on this previously). A good project manager does not manage by spreadsheet or whatever the tool of the day is. A good PM proactively addresses issues, risk, and day to day tasks. A good PM understands the dependencies of a project and when a developer says, “The DBA still hasn’t run my sql script” the PM understands it to mean, “My developer is dead in the water tomorrow because he was supposed to start the task hitting that database tomorrow.” I’ve seen too many project fail because the PM wanted to document a project instead of lead it.
—————————-
OK, what are your thoughts on failed portal projects?
Nice Article Mike…But this article applies to all the stream of Software Development Process not just the portal technology.
You make a good point. Any project can make these mistakes. I focus on portal and collab and so my “rose colored glasses” point me in that direction. I would say that in general, PM’s try to spend too much time coordinating and not enough time leading a project.