Bernard Williams - IT Research Blog

Knowledge Management in Technical Organizations

Introduction

When a highly productive fruit picker, or apprentice carpenter, walks off the job, there is typically someone waiting in the wings to take their place.  The new employee will need very little time to come up to speed and start being productive. Contrast that with the software architect single handedly responsible for designing the majority of your current smash hit product.  The competition gets her name and starts recruiting her heavily.  As a result, your company loses her to the competition right before the big launch of the new product. On top of that, there are issues with the previous version that are impacting your current customers that no one else can figure out.  Very little is documented. Most of the material that is documented was done by the marketing team.  Your remaining team members struggle to learn the architecture and spend a lot of time writing down what should have been written down before.  This is time that could have been spent on issue resolution or preparing for the new launch.  Your company will take a long time to recover from the loss of key knowledge workers with or without good documentation.   Having a good knowledge management strategy can help retain organizational capabilities, speed the training of new hires and improve the quality of the products/services your team delivers.

Unfortunately, it's a lot easier to say knowledge management than it is to implement it. There are numerous reasons why organizations resist the need to capture, retain, diffuse, and synthesize knowledge.    They range from organizational culture to blissful ignorance of the incalculable costs.   When an organization does embark on a knowledge management initiative the effort often fails.   

Why knowledge management fails

I will be writing on this over the next several weeks, however the primary reasons pointed to in the literature are organizational culture, managerial commitment, and an overall inability to execute.  Lastly I will talk about what you as a manager can do to help drive knowledge management in your organization.

Software Development Project Problems: The Never Ending Story

This situation happens time and time again.  In fact, most of you can probably recite the story without much in the way of coaching.  For the project manager tasked to make the impossible happen it goes a little something like this:

1. Someone with more time on their hands than you assigns you a software development project.
2. They tell you that this is a “straight forward” engagement and that you should be able to get it knocked out along with your other assignments.
3. They leave out the part that due to an “expert” sales job, the customer is expecting the deliverable twice as fast as you were told you needed to deliver it.
4. You get assigned a project team and are promptly “notified” that several key members of the development team will not be available to work on the project until 3 weeks after the initial customer committed delivery date has passed.  The resource manager is surprised that no one told you.
5. The only breathing thing on the face of the planet that loves you unconditionally (your dog) runs away.
6. The customer calls you and tells you that they are tired of your organizations consistent lack of software quality and inability to deliver on commitments, and that you had better get this project right or they are leaving.  They wonder when (if ever) you are going to reverse your current state of rectal cranial inversion.
7. During the project kickoff with the customer, you learn that there are several key deliverables that they are expecting that are not in the contract.  Your management asks you why you can’t just “slip them in”.
8. Your dog returns and without hesitation (or your knowledge), urinates on the kitchen floor while you are in the other room working feverishly on your resume and shamelessly slaughtering a tub of Ben and Jerry’s.
9. You slip and fall in your own house, soaking your best shirt in your dogs pee, and quietly wonder in the back of your mind if things could get any worse.
10. It does: Your customer calls you at home – The sales guy was nice enough to give him the number.  The solution that you deployed has died and they are refusing to sign-off on the six-figure invoice you sent them.  It’s the end of quarter and your manager wants to know why it is you can’t deliver the “easy” project that they handed you.

While this sequence events may seem drastic, it happens all too often.  Albeit, without the dog ☺.  It doesn’t have to be this way, however.  Proper planning, preparation and a healthy dose of reality can go a long way in reducing an organizations’ need to manage by crisis.

There is a theme in the relevant literature that IT project failure is largely a social, people based, phenomenon that can be mitigated with improved thinking/behavior on the part of project participants.  (Amble, 2006; Glaser, 2005; Keil, 1995; Keil, Mixon, Saarinen, & Tuunainen, 1995; Young, 2003)

People have to work together effectively and efficiently to make it happen.  More often than not, there are poorly trained/equipped individuals who cause the majority of software development disasters in an organization. They eschew best practices in favor of no or inadequate processes.  They resist process improvement because they don’t understand it, and they are exceptional at protecting their turf from the scourge of new ideas.  Sutterfield et al (2006), provide a detailed description of a Department of Defense project that demonstrates just this type of situation.  According to their paper there were individuals who actively worked against the project in an effort to sabotage a viable technology project that the team was assigned to complete.

In subsequent blogs I hope to talk about how to navigate the minefield of organizational culture when working on large scale project implementations.  I welcome any comments or additional tales of project terror.

Regards,

Bernard



References

• Amble, B. (2006). Silence - the root cause of project failure. Management Issues   Retrieved February 16th, 2008, from http://www.management-issues.com/2006/10/11/research/silence-the-root-cause-of-project-failure.asp
• Glaser, J. (2005). more on management's role in IT project failures. Healthcare Financial Management, 59(1), 82-84.
• Keil, M. (1995). Pulling the Plug: Software Project Managment and the Problem of Project Escalation. MIS Quarterly, 19(4), 421.
• Keil, M., Mixon, R., Saarinen, T., & Tuunainen, V. (1995). Understanding runaway information technology projects: Results from an international research program based on escalation theory. Journal of Management Information Systems, 11(3), 65.
• Sutterfield, J. S., Friday-Stroud, S. S., & Shivers-Blackwell, S. L. (2006). A CASE STUDY OF PROJECT AND STAKEHOLDER MANAGEMENT FAILURES: LESSONS LEARNED. Project Management Journal, 37(5), 26.
• Young, S. (2003). Why IT projects fail. Computerworld, 37(34), 44.

IT Project Process Adoption

If everyone sees and understands what should be done on an IT project, why don't more people do it. Why don't more people adhere to well defined and proven methodologies for project success. Today we don't have same excuses that we did in the early days of the digital revolution. We are older and wiser now and have much more information at our disposal. So why don't we follow the recipes for success?

My research in this area seeks to illuminate this area by developing an understanding of the key drivers for IT process adoption.  Through the use of a survey instrument I hope to develop a deeper knowledge of the impact these key areas on adoption.   

Here you will find portions of my research findings and the survey results. Please feel free to comment or critique.

IT Projects Still Fail at an Alarming Rate

It has been almost 13 years since the original Standish Groupreport on Chaosin the software development field and things have not gotten a ll that much better. In a 2007 article posted on SDTimes, the Standish Group revealed that Projects described as challenged, meaning they had cost or time overruns or didn’t fully meet the user’s needs, declined to 46 percent in 2006 from 52.7 percent in 1994. That is a welcome albeit, meager level of improvement. Do you ever wonder why it is that we in the IT field just cant seem to get our act together and stop spending vast sums of capital on initiatives that are doomed to fail from the start? There is enough blame to go around for everyone. I believe, and the literature on the subject supports, that the root cause of IT project failure really comes down to people. In a 2003 ComputerWorld article, consultant Sue Young summed it up quite nicely when she remarked that " The myth of IT is that it's about computers and technology. It's not -- IT is about people."

I often see organizations struggle against sanity, and rejoice when they defeat it. Its is truly an amazing thing to watch people convince themselves that tasks that should take weeks or months to do can be compressed into days without sacrificing quality. Next, I watch those organizations race to find the appropriate person (or people) to blame when the plans fall through and the customer is unhappy.

All in all, there appears to be a resurgence of the chaos that was common during the buildup of the dot com implosion. I hope we can stop this through education and training before it gets out of control. I hope that we can find a way to let sanity win every once in a while.

This site provides some interesting failure examples and points to a contrary viewpoint surrounding IT Project failure.

Six Sigma and IT Development: Are They Meant to Be Together?

Abstract
Information Technology and how it is used are both becoming commoditized and eroding organizations previous technology-based, competitive advantage. (Carr, 2003) At the same time Six Sigma has risen in prominence. This article will review the literature as it applies to IT sector organizations; identify the people, process and policy issues that effect the adoption of Six Sigma in IT sector firms, with the thought of articulating best practices that could work to improve the rate of Six Sigma adoption in IT sector organizations.