Skip to main content

Follow-up: How to run your IS department


Some of my friends told me that they enjoyed my blog posting titled "How to run your IS department", although I did hear a consistent message in their feedback. While they seemed to agree with the content of my posting, the general sense was that it sounded like I was complaining without offering any concrete solutions. Well, I'm glad to say that I already had solutions in mind when I made the original posting.

Let me start of by saying that I'm not claiming that these ideas are 100% mine because they're not. Rather, they mostly stem from other sources that I have gleaned over the past year while trying to learn more about Scrum and other best practices. Never the less they will help any leaders that are trying to improve how IS is viewed by their organization.

Get People Outside of IS to Sponsor Your Projects

In Scrum that is the role of the Product Owner. IS rarely creates projects solely for themselves; rather the project has some value to the business. Find someone such as a manager of another department to fill that role. They are going to be a lot more committed to a project if they are an integral part of.

This in stark contrast to having IS creating something in isolation and simply handing it off once they are finished. All too often I have seen a business units being handed an application and very quickly they would start to complain about how it doesn't meet their needs. By making the key stake holder a part of the team, the success of the project is as much as reflection on them as it is on the rest of the contributors.

Build Relationships

This may seem like a no-brainer, but if you are introducing changes to an organization it's a lot better if you already have the faith of some of the key players. Depending on where you are starting from, you may have to start small. Simply show that you care about their problems and go the extra mile to solve them. Over time they will see you as a person that gets things done and will (hopefully) start to believe in you.

Don't fall into the trap of playing a strictly subservient role. Show them that you have the same goals as they do, and you know of ways to meet their goals. Collaboration is a two way street so be sure to offer your ideas an suggestions. Otherwise you'll be more viewed as a helper as opposed to someone that can counted on to bring about positive change .

It may go without saying but also pay attention to who you want to notice you. Every organization is different and part of the trick is finding out who really matters. In some organizations the people at the top may be too far removed from what you're doing. Try to get a sense of who is getting things done in your view of the world.

Sell Something Concrete

If you are trying to introduce change to an organization, there needs to be a clear benefit to what you're proposing. If you simply say something like "We're introducing Scrum", it's going to be a hard sell to people that aren't already familiar with it. Instead focus on the concrete benefits such as "Increased Productivity", "Quicker Turnaround", or "Less Waste". Those are all things that a CEO can get behind.

The biggest mistake you can make is trying to get people to buy into something to which the benefits are not clear. If anything they will assume that you are simply following the latest fad, and that this is all just a waste of time.

Additionally, once you've had a successful project under your belt, people will be much more likely to try this new way of doing things that you are proposing. The selling process will be that much easier.


As always your feedback is much appreciated!

Comments

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

The Retrospective From Hell

Over the last 17 years of my career I'd like to think that I've learned a lot. I've learned from positive role models, from experience of what works well, by studying my craft, and from my own trials and tribulations. However, I believe the lessons that I have learned that had the biggest impact is learning from failures. One such failure occurred at a previous employer. By telling the story of a past failure, we can reflect and see what can be learned from it. No names will be mentioned, no embellishment or poetic license will be will used. As a matter of fact, I will make every attempt to be objective and accurate as possible. The truth of the matter the story doesn't need it; it speaks for itself. Some time ago I worked for a company that, among other things, had a software product. There was a small team of software developers, and someone that acted as the manager of the team. I was brought on board, as a software engineer, to help with the software product as

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