IT Transparency

  • Comments posted to this topic are about the item IT Transparency

  • We (local council with 500+ permanent employees) had the same issues (our efforts were not visible + company vs. individual view) and solved it in the same manner - using SharePoint at the time.

    Broke it into "issues to resolve" and "unexpected problems"...and added "scheduled outages" as well.

    Also made the list public.

    And made the escalation process talk to me, if you don't like it get your boss to talk to my boss, short business case for bumping up the priority and that filters back down again one way or the other.

    And the biggie - the into 2 levels of support, general (1st level) and app (2nd level).

    All those phone calls to developers "just because you know them / their extension" were met by "What's your case reference?" and "Oh, don't have one? Well log it with the helpdesk and we'll get on to it." and "If it's that urgent (aka you think you're THAT important) get your boss to talk to my boss".

    We realised we lost no end of time to answering daft calls or answering the same thing over & over ("yes, the server blew up, that's why your application is not working") so the new process was more cumbersome but significantly more productive overall.

    And people always react better to knowing the worst than not knowing...

    Andy Davies

  • Great article!

    As a CIO for 8 years, I have tried various reports, meetings, change request processes, and other forms of transparency in the past, and I've always run into two problems. No one read the reports, no one wanted to follow the processes, and no one wanted to attend the meetings. They wanted what they wanted, they wanted it now, and they didn't want to do anything to get it. I'm definitely going to give your idea a try. It sounds like a great way to get buy-in on the prioritization of projects!


    VP, Information Technology

  • Great article - and of course we've faced the same issues. Since I'm NOT a manager, I couldn't implement such a solution at a higher level, but advocated doing so. Our new Chief Technology Officer (CTO) seems to be doing some similar things, although as far as I know there's not a global meeting yet. But hey, he's only been here 2 months! Right now he's doing the "attend as many meetings as possible" thing just to figure out where the department is at, but the improvements are starting to show.

    One item on his list is to get a "real" problem tracking (ticketing) system that anyone will have access to so the users can track their problems thru resolution and see what the status is (without calling their favorite programmer!)

    I forwarded your article to the CTO as well as my workmates; might give us another avenue to get the priorities properly set! Thanks for sharing your experience.

    Here there be dragons...,

    Steph Brown

  • Andy, I totally agree - better to know than not! Have to overcome the core fear of admitting the problem, but it's a great way to reduce stress just having it out in the open.

    Elizabeth, thanks for the comments and I hope it gives you the starting point to something that works. I'm a pragmatic guy, anything that works is better than something that doesn't. I think I had a lot of luck making my solution work, the one thing that tipped the balance was that I was totally willing to admit any & all mistakes and to make them very visible!

    I've got a small prequel post on my blog that you might find interesting as well -

  • I agree a real tracking system is a must. I vote for the cheapest & easiest one you can buy. We built ours at the time and I consider that to be a mistake, would have been better off just conforming to someone elses implementation. But either way, have to have it.

    You're right that if you're not a higher level manager you can't directly implement, only try to influence - which you seem to be doing! One thing I've thought about and discussed in other posts - but not actually tried yet - is that I think a departmental or team blog might be another way to open up the process. Imagine you have three DBA's that maintain one central DBA blog. Any time there is a reboot scheduled, any type of issue, patches added, post some not too technical notes about why/how long/etc. When you send out the company wide email "server will be down for maint" instead of putting the explanation in the email, point to the blog. Not a lot of people will read it, but a few will, and if you stick to the same idea of being totally honest and open, sooner or later that builds cred with those that matter. It's also one of those nice things your boss can point out to other managers as far as transparency, using the "latest" technology aka blogs, etc!

  • Great article.

    In my last place the Service Ops Manager tried to get something similar set up, with me trying to help it along - we had change control, but this was often circumvented. Unfortunately, though our Director agreed with it all, he never 'visibly' supported it - he was also the protagonist in getting round change control. This was the killer. The trouble was there was no-one to filter the work to the team, which meant it was chaos.

    Unfortunately, they are still suffering today, with the Service Ops Manager still trying to get proper controls and functions in-place, and is still trying to have the support of his Director. Me, I left, along with a number of others. This wasn't the only reason for leaving, but it played a major part. So, these sort of processes help all of the business, including those in the IT business unit.

  • Andy,

    What a thought provoking article! I can see the value in my organization immediately. And while I am not a manager, I passed the article on to 2 people who are and to the CIO. I even sent it to our former CIO because it was so in line with her thinking.

    While the full solution may not work for everybody, I can certainly see where most companies can gain some positives from such an approach.

    Thanks for the great read!

    Buy the ticket, take the ride. -- Hunter S. Thompson

  • Humble, you're right on the money - if the chain of command doesn't support it, damned hard to make it work. More often they want to, but seem to run afoul of the pressures of daily corporate life. You can't see the full benefits without everyone participating, but even if your team just starts and lives by the process everyone will benefit. Not as much fun to go it alone, but it can still be fun, and useful too.

  • Bryant, thanks for the comments and compliment. Everyone needs to find their own formula, but it's worth spending some time to 'war game' the process from all sides before you field it, how will people try to get around it, who is the weak link in the process, how do you assure the higher leaders that you won't run the company off the cliff because you stuck to your plan?

  • Great article. Exposing your failures as well as your victories can also makes people less prone to fail. None of us like to see our mistakes made public, with that in mind most, in a transparent organization, most will be happy to put out the extra effort required to eliminate, to their best ability, mistakes. As a team this can lead to greater mentoring between and cooperation among team members.

  • We had a similar setup at my last company as well. The two problems I faced were 1) CIO who always wanted to short cirut the system even though the CIO championed the meeting in the first place. and 2) my development team was also the production support team (small IT shop) so support issues came first and could cause havoc to the schedule. We also had to watch out for enhancement requests that came into our team as production support bugs -- these needed to be rerouted through the weekly meeting.

  • We had a lot of the same challenges, until we started publishing IT's to-do list as part of the documents going out with the roundtable announcements.

    It sometimes helps to expose just how far into the "hole" your staff might be. We had 5 years' worth of project requests we couldn't even start on. Like you mentioned - having that backlog exposed tends to put individual department requests into focus, and helps enlist the departments into the cause of helping IT with their personnel shortfalls...

    There now is a form of self-governance in place, with key IT and non-IT players meeting to review and assess new project requests as they come in. Makes it a lot less thorny, since the process is open for review, and better feedback is provided.

    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Great article!

    Andy and I have talked about this for years and I thought this was a great technique for managing things in a small environment. We had something similar in a large company (10,000 people, 500+ in IT) and it didn't work as well, but the idea was the same. Air out the current priorities and schedules and work through them so everyone is aware.

    It definitely requires buy in from the top!

  • Thank you for bringing up this important PM topic. Transparency is essential for IT survival. We are engaged in a 18-month project re-enginerring our processing model from SAS to SQL. It is too easy to busily bury ourselves in that "black box" without the executives knowing what and how such a big team (30% of the company) is doing. By having weekly one-hour Monday meetings involving top executives, operations managers, and domain experts, we go over project status, resource issues, potential schedule slippery and budget overrun, and also listen to them for their guidance. That is followed by a comprehensive Minutes email the next day. Our goal is keep them well informed and avoid big surprises. It seems to be effective - we had some challenges in some milestones in terms of delivery and the top management was quite understanding.

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic. Login to reply