Cowboys

[nick_CHA]

Hi,

I am struggling to convince my IT Team of the advantages of communication and management of incidents, problems, tasks, resources, etc. (Yes, basically everything)

1/
For example, I ask a DBA to implement backups of a database by date X. I send this action by emial to several people involved. Date X-2 arrives and we sit down for progress review and DBA either denies accepting the task or says they forgot , says sorry and says they will do it by the end of the day.
End of day comes and I get an email. Subject: have started the backup of database D
Body of email: Empty

This is all on a production system/database, etc. No change raised in change system.

2/
Our 24x7 product website stops working properly. It takes a week and 3 people to fix it. No helpdesk call is raised. No evidence of the problem ever happening exists - except maybe a few emails in various peoples inboxes.

3/
Similar to 1/ but doc specific.
System infrastructure upgrade. 1 component is db upgrade.
DBA (a temp consultant) has implemented a new database cluster with hot standby and good backups and tested it. I know he has tested it because he says he has. I know what servers they sit on but little else.

Users have tested comprehensivley on the new platform.

The project goes live after 1 year and several people involved. No change is raised in our (expensive) change management system.
Final deliverables:
a) an email saying well done. (actually, no there was an initial proposal document containing details of the new infrastructure/software versions)
b) UAT plan
No implementation spec, No support document, No test plans or results of the infrastructure.

3 of us now take turns providing 24x7 support.

-------------

Do I kill myself now?
How do i convince management that they arent managing?
And the impossible one: How do I convince people that documentation is required - for due diligence and actual use by IT support? What other reasons are there?

I agree that documentation is a lot of effort. And it's bound to become out of date. But, ZERO knowledge?

I must stop writing now.

[nick_CHA]

Oops I meant to stop at point 1/ !!

>End of day comes and I get an email. Subject: have started the backup of database D
>Body of email: Empty

What should be provided?

We have 3 sites and 500 users.

[m_croon]

Hi Nick,

My first reaction when I read your post: what are you doing here? This is certainly not about ITIL, but about corporate identity/culture. However, you describe your problem very vividly and I'd say we ought to respond to your cry of help (NO NO, don't jump, don't do it )

What is your role? Are you working under the management team you mentioned? Are you their director?

Just some loose thoughts that come to mind, your 'island hopping' causes me to respond likewise I feel I do not have enough info about your situation to point out 'what went wrong', but maybe I can give you some suggestions to work further on this subject yourself.

First of all: can you sack the dba (after all, he is a temp). Set an example of 'how we not do things'. this can be a part of the 'stick', whilst the carrot could be something like this:

1. check on the internet (google): John P. Kotter's 8 steps for succesfull change.
2A. get keyplayers from the project together, and as an evaluation, go through all 8 Kotter-steps and try and define what went wrong. Doing this as a group might open people's eyes. Or you can:
2B. walk though the Kotter steps yourselve, and use it as a means to determine what went wrong.

3. Reporting to customer
What / how / how often does your operation report to your customer? Very simple and short (but S.M.A.R.T.) reports will do, weekly or monthly, depending on your organisation. The best way of forcing change upon your organisation is an angry customer. Give the customer the chance to discover that there were no changes for this important project. If they care, you have a powerfull instrument to tell people to log changes from now on. And if they don't care, why should you?

Hope this helps,

Michiel

[nick_CHA]

Thank you very much for your reply, Michiel. Thanks to you I didnt jump

I'm a techie.
I have no authority over people. I am a technical authority for many systems/technologies.

I often feel like I am trying to tell my 'superiors' how to do their jobs! This makes me hesitate and step back. I'm not known for my tact, but I know when I need to draw the line!

Our DBA is skilled but young and disorganised. I would rather help him improve the way he works. To do this without targetting him I believe I need my superiors to buy-in to the need to improve things and to lay down the law.

Kotter's 8 steps - never heard of him before. I will try your 2B suggestion because there is a ridiculous opinion throughout the team that that kind of concept thing is corporate BS and overkill for our environment - partly true - after all, we have real work to do! "People are moved toward change when their emotions are engaged." - great quote.
However, change is not a problem - it's considered and planned change that doesnt happen.


Reporting is a good idea. I have made huge efforts to improve my communications to manager, team + customers for incidents, changes, projects - however, I am going to take your suggestion onboard and try weekly reports for Projects instead of adhoc communications as things are done or change. I need to tune my ms project skills as I fight with it at the moment.

Customers not caring? Believe it or not, I actually think they are too nice to get angry!! I know this because I got drunk with one and it all came flooding out. It's weird because usually, customers are constantly screaming and whining!

Thanks for letting me rant.

Basically, I will try to: 1) try to motivate management to manage and enforce some kind of quality/thoroughness in what we do 2) continue and improve my personal way of doing things 3) try to accept that continuous improvement is going to be a gradual process.

However, as Deadline date looms, and progress is delayed, the first things to be cut will be Testing, DR, Backups, Implementation planning - actually they will initially be cut in half by removing the documentation. "Oh yes, I can do the testing in half the time if we don't need to produce a test plan and report" Yes, I bet you can.

--Nick

[m_croon]

Nick,

You're welcome! However, it seems to me that your name is Dilbert!!

I'd say you do have a couple of advantages on your side:
* You have a good, although possibly foggy relationship with at least one customer. Use it to his/her benefit!
* You are willing to help the dba. Why not confront him with your opinion in a safe environment / safe moment (to make him aware, not to destroy the guy). If he is young, you'll give him a life-lasting lesson that might just turn him into a very responsible being.

Re. the quote on change: I think that you'll find at least one of Kotter's steps that will cover exactly this topic (sense of urgency, leading coalition etc.).

PS: Ranting is the mother of all quality improvement, don't stop doin' it.

[Guerino1]

Hello Nick,

Forget about ITIL, you've got a much bigger problem. You're in a small fly-by-the-seat-of-your-pants company. You are not alone. There are more of you than there are structured and highly organized organizations, out there. However, all companies that grow start to hit growing pains and need to start to put constraints, structure, and process in place to allow for future and additional growth. It's a natural and consistent law of size and scale (described best by magic number theory).

As a result, the first and most productive process to put in place is usually some light form of Project Management. Think of it as putting an orchestra conductor in front of an orchestra that never knew how to play together, before.

You say your not that tactful but I believe that, based on your response, you are far more tactful than you want to give yourself credit for. I believe you should leverage your understanding of the situation to help solve the problem. Here are some steps I suggest:

1) Print your post, strip out the "contentious" things, and bring it to a superior you can trust and have the conversation with him/her about your feelings on the situation. However, and it's critical you understand this, you can't go to him/her without options. Real leaders don't present problems and run. They present problems, their impact, and options for fixing them, with viable returns on investment.

Therefore:

2) Put a list of small, light-weight options together that can help improve the situation. For example:

- Manage your projects through a loosely structured spreadsheet, where you can list project related tasks and accummulate data, ove time.
- All tasks get put into the spreadsheet under their relevant project, with colums for: Task Name, Description, Status, who's accountable for it, date assigned, date due, deliverable, who gets the output, how many hours of work were actually invested, total task duration, etc.
- The spreadsheet gets mailed out twice a week to all employees.

3) List the things that you believe will improve and what the impact of the improvement will be to the leadership. Go after any low-hanging fruit, first.

4) Offer to take accountability for updating the spreadsheet and mailing it out to people. They can email you their updates so you can update it for them. NOTE: Keep all copies of mailings to address people saying that they never saw the task or never heard of it. Also, by teaching them that you will be expecting updates for management and coming after them for these updates, they will usually start to fall in line. You may have to start this step without real buy-in to collect some tangible data that you can use for suggestion #1.

5) Offer to sit down with the leadership once a week to quickly go over the project work in the spreadsheet and the status of everything. Once you do this, they will see for themselves, what the reality of the situation is.

6) Realize that you can't fix everything. Mountains get moved a few stones at a time and if you don't start now the mountain will never be moved. Pick small controlled things to manage first, then slowly start to expand. As time goes on, get people to help you update and manage the spreadsheets/plans. Eventually, what everyone hated will be something they're all addicted to and rely on. Funny thing about change... once it's accepted, it's the thing nobody wants to change away from the next time new change is introduced...

If you can do these types of things in a very light-weight way, you will win their approval. The other bright side is that you will have stepped in as a proactive problem solver and it will raise your visibility to them and get them to see you as a "leader" not just a techie.

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[itilimp]

*grins* I recognise an awful lot of what you say and all I can say is that having an occasional rant can be healthy as frequently buried within it will be a gem that can help you make positive improvements in your work place.

I just wanted to post and second taking the time to read Kotter's work on leading change. It can apply to ANY type of organisation / people change. Simple yet very powerful.

[nick_CHA]

[Guerino1]

[quote="nick_CHA"]