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:

1. Information Architecture
2. Technical Architecture
3. 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:

1. Is this technology project going to increase our revenue?
2. Is this technology project going to reduce costs?
3. 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?

Bookmark It

Hide Sites

This bridge will only take you halfway there
To those mysterious lands you long to see :
Through gypsy camps and swirling Arab fairs
And moonlit woods where unicorns run free
So come and walk awhile with me and share
The twisting trails and wondrous worlds I’ve known.
But this bridge will only take you halfway there –
The last few steps you’ll have to take alone.

- Shel Silverstein

That poem is pretty much committed to memory for me right now as I regularly read “A Light in the Attic” to my girls before they go to bed, and we always end with a reading of that poem.  Today, however, it carried a new meaning as I was working with one of our project teams at work.  We were analyzing a customer’s business process and I started to educate them on some UML and software design elements for breaking down the business process into components.  I introduced concepts such as actors, componentizing of classes such as customers, sales person, and the properties or metadata that applied to them.  Really I was trying to get them to look across the mass of Excel spreadsheets that the business was currently using to run its internal operations and break it down into class diagrams, activities, state changes, and use cases.

There are a few things that seemed to linger with me after the initial exercise and meeting in which I was trying to communicate these concepts I had learned through years of IT and development projects.

1.     Many of these concepts were foreign to the team (and sometimes I felt like I was speaking Greek to them.. although it was probably just “Geek”)

2.     None of the team members had a technology background or education (mostly MBA’s and finance backgrounds)

3.     The intern of the group related to the concepts faster than the other team members

4.     Once they “got” it they immediately understood the benefit of the exercise I was taking them through

So here I sit reflecting on the process and scratching my head as to why more disciplines are not getting exposure to some of these concepts that us technology oriented people have lived and breathed for years.  I read every day on Web 2.0, Enterprise 2.0, aligning technology to the business, how technology can create new business opportunities, but the very core methodologies that make these efforts successful are not even being mentioned to the millennial generation.  It doesn’t matter if we are talking cloud computing, Web 2.0, social media, etc. successful business process modeling techniques are still very important skills to learn in the business world.  Honestly I believe they are even MORE important in this day and age of technology than they were when I first learned them.  With information being stored across systems and network infrastructures keeping with my core tenets of a successful IT program becomes harder every day.

Over the years I have found that my “career upbringing” has armed me with some very powerful skills as I moved into the business leadership roles I’ve been in as of late.  System design, object oriented programming, process modeling, focusing on core capabilities, thinking outside of the box are all skills I’ve learned as a technology professional.  The evolution or revolution as I call it, has been that these methodologies and teachings have great application to the business world.  I learned about continuous process improvement from CMMI, process modeling through development and UML concepts, problem solving and communication through system administration and help desk, and collaboration and “networks” in my hardcore “router head” days.  All of these concepts I apply and probably more importantly teach regularly in my current leadership role in the organization.

So technology professionals your training and background has more application than designing proper software systems and architectures, and business people your technology professional has more to offer in these times than making sure the email server is running.  But no matter which “role” you play in an organization for people and a team to grow around you and see you as a leader you need to build the bridge for people to be able to take those last few steps.

Bookmark It

Hide Sites