Skip to main content

How to run your IS department


Over the course of being a software developer for the past 10 years, at 5 different employers, I've noticed a reoccurring problem at these organizations. The business leaders simply don't understand what IS does and the value that they can bring to the company. (The one exception being a software consulting company, where IS was their business.)

Most organizations tend to see IS in a similar light as brick layers or plumbers. They are simply there to keep things working. Additionally they are there to build what other business leaders have envision. In this analogy the business leaders are the architects, coming up with the grand designs, while the software people are the construction workers, putting the pieces together.

What the business often fails to realize is that role of IS is to help the business run more efficiently, increases company wide productivity, and most importantly be a strategic asset to the company. In all of my working experience, the software people often best understand how to use technology to help further the needs of the business. Of course they can't build the software without knowledge of the business, but rather there needs to be a collaboration between the business side and technical side.

While I have held these beliefs for quite some time now, I recently came across this article that does a great job of articulating these thoughts. Here are some favorite quotes:

  • There are no IS projects -- only projects designed to solve business problems.
  • Relationships matter. ... When people have built a good relationship there is trust and it's easy to get things done. And it's very difficult to get things done when there is not a relationship built, with the lack of trust that causes.
  • IS must be integrated into the heart of the enterprise, and everyone in IS must collaborate as a peer with those in the business who need what they do.
  • Nobody in IS should ever say, "You're my customer and my job is to make sure you're satisfied," or ask, "What do you want me to do?" Instead, they should say, "My job is to help you and the company succeed," followed by "Show me how you do things now," and "Let's figure out a better way of getting this done.
  • The company's leaders have to collaborate to determine how funds are spent, or the company won't be able to set and implement a strategic direction.
If you have a spare moment or two, I'd highly recommend taking a look at the article. I'd also like to hear your thoughts on the matter. Do you think it's realistic to expect this type of behavior from a business? Is this simply an idealized, IS centric view, or can business effectively run in this manner.

Stay frosty!
Labels:

Comments

Post a Comment

Popular posts from this blog

Value and Quality over Schedules

According to a study by CEB Research, 70% of software projects are delivered on time, but only on 38% meet stakeholder's expectations. In most cases the people that use your software will not even be aware of internal project deadlines. Case in point, think of all of the software the you use everyday. You are rarely aware of what the due date was. However, what you do notice is how well the software does it's job. It's it's of low quality, you'll very likely notice right away. Even if it appears to be of high quality, if it doesn't provide any major value to you, chances are you still stop using it. With that in mind, then why do many software projects today have a set scope and a hard due date? When building software for a customer, it's only natural for them to what to know what exactly they are going to get and what is will cost them. That is a very reasonable thing to want to know. Even when developing software internally, there are often similar expe...
4 comments
Read more

Let's Get Moving With Software Development!

Recently I was reading a discussion on Twitter about software projects, and it reminded me of something. Many years ago I had a conversation with my dad about moving. After just having moved, he wasn't too pleased with the moving experience. He mentioned that there was essentially two models that movers operated under. The first was you paid a fixed price for the move. I don't remember the exact details, but the movers quoted a price most likely along the lines the square footage of the house, or some similar metric. The other model, was simply to pay the movers for their time. If it took them 20 hours to complete the move, you paid for those 20 hours. Now the catch was, as he described it, if you paid for a fixed price the movers didn't really put a lot of care into the move. They simply wanted to get the job done as quickly as possible. I seem to recall that if they broke something, they would reimburse you. However, that wasn't a pain free process. More importantl...
5 comments
Read more

Our Experience With Mob Programming

I was first made aware of Mob Programming well over a year ago. While I've always felt that you can do great work in collaborative environments, I have to admit that at first I was somewhat skeptical of the idea. How could having the entire team work on one thing at a time be as productive as everyone working in parallel?  Having said that I considered myself open minded and am always willing to give something a chance. As mentioned previously, I've had great experiences working collaboratively in teams. In the past I worked on a large team making complex software, and our best work was produced after designing as a group with white boarding sessions and intensive debates about best approaches. I had also worked for a Credit Union, and worked hand in hand with the business to help come up with ideas on how to best utilize technology to solve their business challenges. Only by collaborating as partners were were able to come up with practical solutions that properly addressed...
Post a Comment
Read more