Everyday that goes by technology becomes more and more a part of our daily personal and professional lives. My mother has been saying for years that I am “technology dependent” and my wife even calls my iPhone my best friend (ok so I’m a lost puppy dog when I don’t have it). I remember back to the days in high school and even parts of college where it was unheard of to allow a calculator to perform mathematics, but tell that story to the current generation and most of them cannot fathom the idea. The millennial generation has integrated technology into all aspects of their daily lives, and more of us find that we can’t function without some of the advances that technology has brought us (spell checker anyone?).
I’ve talked in the past on this blog about the challenges the current generation faces from not having sound fundamentals when it comes to technology projects, but another equally important issue is the concept of technology for technology’s sake. What I mean by this phrase is that we can’t just look at technology as the means to solve all of our problems, and simply throwing technology at a business problem is not going to make it go away. When I’m mentoring new technologists and even talking to customers about implementing a technology project one of my favorite phrases is “projects are 80% people and 20% technology and the technology part is easy”. Most of the time the technology part of a project is the easy part, remember at the end of the day it is just a bunch of 1’s and 0’s that tell the computer what to do. The challenge comes in aligning the people and business to the technology. I believe all successful technology/ICT projects focus on three core aspects regardless of the technology you are implementing:
- Information Architecture
- Technical Architecture
- Training and Education
Wikipedia defines Information Architecture as the art of expressing a model or concept of information used in activities that require explicit details of complex systems. The English version of this is the flow of information through the technology, business processes, relationship between information, and it’s relevance to the business process. If we are trying to automate the process of approving a document for public consumption on the public website we might need to go through a formal review and approval process. This process has people that must be a part of this approval (called actors in UML language), and changes to the document happen throughout the process (revisions). Information architecture is the process of mapping who is involved in the process and what that process looks like from beginning to end, and any information that needs to be captured throughout the process (who approved the document, who made edits and changes to the document, what edits and changes they made, what kind of information does this document contain, etc.). This is a critical step in ensuring that the technology solution is delivering business value and provides a roadmap for implementing the technology part of the project.
Business value is the key here, we are not just implementing this technology because it is “cool”. The question(s) to always ask yourself are:
- Is this technology project going to increase our revenue?
- Is this technology project going to reduce costs?
- Is this technology project going to give us a competitive advantage?
I’m open to hearing more suggestions around questions to ask, but in my experience all well intentioned technology projects can be grouped into one or more of those three questions. Making sure the project is answering at least one of those questions is the key to ensuring it is delivering business value.
Technical architecture is the 20% technology part of the project, this is selecting the right technology to meet the business needs and implementing it correctly within the business. Plenty of models and processes exist to ensuring success, but I’d recommend folks take a look into ITIL and the MSF framework as a starting point. The reason I believe that this stage of the project is the easy part is that if you successfully built a sound information architecture this phase of the project is simply mapping those requirements to the features of the technology, understanding any gaps, and addressing them.
Training and education is in my opinion the most important part of a project and the one overlooked the most. Even with a sound information architecture and a sound technical architecture and implementation the system will not deliver the value to the business if nobody uses it. How many times have we been a part of a technology project thinking we delivered the best thing since sliced bread and then nobody used the system? The primary reason is that we skipped this step of the project or didn’t do it well enough. Call it end user adoption, end user training, lunch and learns, or whatever, but making sure the users of the system adopt the technology is the only way to make sure you realize the ROI and business value of the project. This is one of the reasons I’ve embraced and adopted an agile approach with projects, agile doesn’t have to just be focused on projects that have a software development component. The entire purpose of Agile is to iterate a solution over time, delivering value and more important gaining user feedback EARLY in the process. This concept can be applied to any project and especially shines doing technology projects. Constantly gaining and interacting with users during the development process ensures you have correctly understood what they need from the solution, gets them engaged and involved in the project early, and provides the project team with continual feedback. Gaining that early buy in and including the end users as a part of the project team is key to success.
The key thing to understand in this blog post is about the core ideals of doing successful projects, there are many other components described in depth in many different methodologies and project approaches, but if you look across all of them you will see these three concepts as a recurring theme. The rest of the project and concepts in these project methodologies revolve around execution and process. Technologists need to take the above to heart because it is what separates geeks from business savvy geeks!
I’m interested to hear about others peoples experience in delivering successful and unsuccessful technology/ICT projects, can you map the successful ones to containing all of the above components? Which step was excluded in the unsuccessful ones?
