Unless you are of the Steve Jobs ilk, technology is not a strategy for most businesses and non-profits—it is an enabler. Technology is a very magical thing, and can transform almost any business or non-profit, but business outcomes need to drive technology spending. Making sure that every technology investment project focuses on the final business outcome is paramount. Of course, this seems so logical, almost condescending, but industry numbers show that a majority of technology projects fail to deliver expected business outcomes. There are a myriad of reasons technology projects fail; lack of staffing, IT infrastructure limitations and poor business strategy are a few common ones. The fact is, technology project management is difficult. When ever I am asked to manage a technology project, I focus on these 5 keys in order to insure good outcomes:
Good business people. It is very common for project work to be perceived as a “burden” or “un-glamorous”. Front line business teams will many times say they do not have time for project work. The best business people are in key jobs making money and working with customers. Although pulling your best people is difficult, there is nothing worse when your customers and employees cannot use a system but “it is working as designed”. The process of building or customizing IT software is expensive and difficult, and compromises around requirements are made throughout each day. Your best people know when to hold the line, and when to compromise.
Start the requirements process by simulating how the management team will utilize the system. Everyone has heard the phrase you can't manage what you can't measure. Yet reporting and outcomes are many times relegated toward the end of many project life cycles. Spending millions on a large system, and then not knowing if “things are working” happens a lot. If the team “using the system in the future” can envision the report / metrics they will need in the future, everything will “flow” from there.
Immerse the project in client / user feedback. Every attempt needs to be made to allow clients and internal users to see the prototypes, and also be the first pilot users of the system. Even the best business people begin to develop “project speak”. Why things can't be done, using vernacular no one outside the project team understands, and compromising on things that might eventually cause problems.Getting client feedback and front line crew to review prototypes and to pilot the software before wide scale production, will find gaps and allow time for correction.
Be agile. Agile is usually an adjective, but it is also a software development methodology. Regardless of methodology, being agile means adapting to change, delivering pieces rather than the entire project, and places a premium on continuous improvement. Getting software into production and then makes changes based on data and feedback is the best way to stay on budget and deliver a high quality project. If at all possible, never go to production with the “whole enchilada”. Never expose everything all at once to the entire user base.
Do not let “non functional capabilities” surprise. This is especially important on client facing systems. Metrics and functionality are obvious business articulation responsibilities. Security, response time, availability, browser support, device support, printing, error messages / logic, etc etc. are not obvious tasks where business people focus. Many a system or project functionally work perfectly yet fail due to security flaws, unacceptable response time, and error messages that do not make sense. A good operational readiness test will check all the aforementioned before a system goes into production.