Projects, errors, the user experience and planning in 2013

It's February, and many companies are just concluding their financial closing processes for the prior year. It's also a time for stepping back and reviewing the great accomplishments we made in 2012, and finalizing our goals for the coming year. As we reflect on the work that was done, projects completed, our operational effectiveness, and hopefully how IT contributed to the successes of the business, and document these achievements using your company's format of choice, don't forget to use business terms and avoid buzzwords and IT jargon. Once completed, make sure you share this record with everyone within IT so that they can see how their hard work contributed not only to the department's success, but to the company's overall goals as well.


This is also the perfect time to perform an honest and candid assessment of 2012, taking a critical look back to determine what went wrong and where you can improve going forward. A wise person once said to me, "an error is not a mistake until you repeat it." Errors happen, and planning for no errors is an error to begin with. These bumps in the road are actually an important part of all projects that allow us to learn and improve with experience. If you are planning to run a perfect project, you're kidding yourself and setting yourself and your teams up for failure. To combat this inevitability, make sure you assemble the right project team that can handle bumps and are adept at solving them quickly and effectively.



Even though the bumps are unavoidable, use them as opportunities and learn from them. Don't waste time and energy in getting mad and trying to figure out who is to blame. Public witch hunts never work, are a major distraction, and cause a drop in morale. I have made plenty of errors and mistakes in my career, but I have made the most of the opportunity to learn something from each of them. The real failure is not learning and not improving.

Post mortems are an important part of learning, as long as you make them about the learning. These investigations should be positive celebrations of the project completion and its successes, providing an important opportunity for discussion and documentation. Make it part of your culture so that your team becomes more honest about what they did well and what they can do better next time.


This brings us to project planning. What's on your list of 2013 project priorities? It probably looks something like this: Cloud computing, smartphones and mobile, social networking, business intelligence, revenue generation from IT, future trends, etc. All good stuff to work on, but never forget about projects that keep the foundation from crumbling. Are you properly maintaining hardware and software with a lifecycle management process? How about ERP, CRM, customer service and support, PC upgrades and security, just to name a few? In reality, all of these project categories are important.

The priority given to each of the activities will depend upon your company's priorities, the condition of your IT environment, and your IT strategy. However, the key point is not to think the dawn of new technologies makes existing ones no longer relevant. Business processes still rely on systems that execute efficiently and flawlessly. Shareholders, customers and business partners expect nothing less. We've not been given a pass on "yesterday's systems," but instead, must keep one eye focused on the flawless maintenance and delivery of the core IT projects.

Your 2013 project portfolio should include doing the work required to keep costs low, while simultaneously delivering on time and with high quality. It's critically important to prohibit the "want to work on" projects to take priority over the "need to work on projects." Demand continuous improvement in all IT functions, including the most basic, expecting nothing less from yourself and your staff.


Lastly, with all of this project talk let's not forget about why IT works so hard in the first place -- to support our end users! That's right, we don't create solutions for ourselves (for the most part), we create it for our businesses. Of course we start the project with a detailed and accurate set of requirements which include how the solution will operate. However, most of the time requirements are business and function-focused, and don't include the "user experience." This is a commonly overlooked area of requirements gathering, but to me it is the most important because it is the emotional connection for the people for whom the IT solution is being designed.

When gathering requirements, make sure to specify in detail how the interface will look and how it will work visually. Ask yourself, who will be the ultimate end user(s) of this particular application? Whether an engineer, a pilot, a doctor, an office administrator, a salesperson, etc. -- each of these inpiduals interacts with technology differently, each with its own unique set of priorities and preferences. There is no one-size-fits-all solution, meaning that depending upon the needs of the end user, the same solution may need to be designed in a variety of ways. Oh and in case I need remind you, assess the need for mobile capability from the beginning and design accordingly.

With an eye toward continued improvement and refinement, documenting the lessons learned from 2012 and putting them to work for you and your team can result in a more productive and strategic 2013. It's an excellent way to demonstrate to the corporation that you are driving value, not just keeping the lights on.

This article is published as part of the IDG Contributor Network. Want to Join?

Computerworld's IT Salary Survey 2017 results
Shop Tech Products at Amazon