Successful:
My company was tasked with building a social media presence and letting our web visitors know by integrating relative elements throughout our site. The general plan was outlined as follows:
- Determine which venues to participate in
- Develop initial content and determine the frequency and responsible parties for upkeep
- Determine our site locations to push these new social media venues
- Design and integrate new social media calls-to-action
One of the most challenging aspects was putting the players in place that would be responsible for the ongoing maintenance and upkeep of our social media presence. For example, on Facebook we decided to post three items daily - this meant someone had to decide what content was relevant to the Facebook audience, get the content's distribution approved, and be responsible for the comment and questions that would ensue.
Another interesting aspect was the site integration. With our given site architecture, it was determined that we could reuse a 'control' that was already present in many of our site's templates. By re-purposing this existing content, the integration process was streamlined and avoided many of the potential bugs slip through during a normal site-wide change.
Disastrous:
My company began the implementation of a new version of their flagship application. The goal was to provide the same stability of the earlier version while adding additional functionality and an improved user interface.
From the beginning there was a division between the DBA manager, an influential stake holder, and the Project Manager. The key difference was as follows:
- The DBA manager wanted to use SQL express keeping the new version of the application consistent with the older version of the application.
- The Project Manger wanted to use Compact C believing the new version needed to go in a different direction.
The project manager eventually persuaded the majority of the decision makers/stake holders to go with Compact C. Unfortunately this was done without ever getting true buy in from the DBA manager.
Ultimately the application was delivered, but wrought with errors and glitches. Customer satisfaction was very low and eventually the issue became so serious that an emergency decision was made to switch to SQL Express and the project manager was terminated. The Switch to SQL Express created new complications that our company continues to work through.
Listed below are a couple of red flags that forewarned of impending disaster:
- Project Manger requested resources that were then separated from their colleagues working on the earlier version of the application. This led to a feeling that the new application team was separate from the rest of the company.
- The QC testing process was not well planned. Huge errors and glitches that should be caught in the QC process made it through, not because QC employees were not working hard, but because the process was not well designed.
- The application support manual was not integrated into the application development process. Due to this there was a rush to deliver a manual to customers with the application.
- Scope, Time, and Cost collided violently, leading to the delivery of the application well before the project manager believed it was ready. This contributed greatly to low customer satisfaction.
In closing this project was undone in the early phases and the company is still bearing the cost.
Differences:
The major differences seem to be in the team commitment and the planning times involved. For our successful project, we had a full buy-in from all of the major players including our CEO, Marketing director, Web team leader, on down to our designers. The disastrous project had disagreements from the project's inception. The successful project had a solid plan that was then followed with a logical workflow and division of responsibilities. Lack of quality control and planning seemed to cause the disastrous project to suffer.
No comments:
Post a Comment