In my experience; even in technology-lead businesses, IT Departments very VERY rarely take the lead in process improvements / modifications. Such organisational changes are ususally driven from the very top-down from requirements sent from individual departments.
Think about a sales team's requirements for faster processing of new orders. Do they go to the IT department to ask for a copy of ABC Processing Inc.'s latest off-the-shelf software? No, they route their request up through the ranks to ensure that their request fits in with the business' overall key objectives, financial plans, current / planned processing and organisational structure etc.
When that sales team changes the way they manually process orders and create delays as a result, the MD / CEO will undoubtedly ask "Why the hell was the IT department leading the change in one of our core processes"?
Why is this? Because the IT Department (perhaps CIO-centric) are not the sales specialists of the organisation, the sales team itself is. Change, in a well-structured organisation, comes from the top; from real leaders.
This, of course, is the case regardless of the department requiring process modification and I only use sales as an example.
CIO Leading process change? If thats what happens in organisations you're familiar with, then the top ONE reason such projects fail is because they were given to the wrong person to lead.
Want a SUCCESSFUL technology solution? Follow these simple steps:
Business Requirement
Technical Specification
Technical Solutions
Business Acceptance
User Acceptance Testing
Business Acceptance
Deployment
Review Review Review
Business Sign-off
Funny, but I think you may also find Prince2 helps in managing projects PROPERLY.
Discussion on:
View:
Show:
"If you want to see what failure truly looks like, attempt to reengineer a process without ensuring that all of those with a stake in the process are represented during the effort."
That pretty much sums up what I've seen at this organization. The requirements were written by those who had a superficial understanding of the process and who used it only rarely or who filled in when the subject matter expert was on vacation. One subject matter expert was not consulted at all, and a hardcopy of the requirements was thrown on her desk after the fact -- she wasn't even privy as to where the electronic copy was located and had never been invited to any of the planning meetings! The other subject matter expert was consulted for 15 minutes tops.
Needless to say, when the project moved to UAT, it was a absolute disaster. It was at this point that one of the subject matter experts was pulled in, only to find that the process was totally unsuitable. After having spent thousands of dollars, the organization pushed the project onto the back burner for retooling and then months later made a second attempt, still using much of the code from the first try. The process "works" now, with a myriad of workarounds and hands-on management required. If this organization didn't have big pockets, someone's head surely would have rolled for such mismanagement.
After having participated in this fiasco, anyone can readily understand why this IT organization's internal applications are absolutely terrible.
That pretty much sums up what I've seen at this organization. The requirements were written by those who had a superficial understanding of the process and who used it only rarely or who filled in when the subject matter expert was on vacation. One subject matter expert was not consulted at all, and a hardcopy of the requirements was thrown on her desk after the fact -- she wasn't even privy as to where the electronic copy was located and had never been invited to any of the planning meetings! The other subject matter expert was consulted for 15 minutes tops.
Needless to say, when the project moved to UAT, it was a absolute disaster. It was at this point that one of the subject matter experts was pulled in, only to find that the process was totally unsuitable. After having spent thousands of dollars, the organization pushed the project onto the back burner for retooling and then months later made a second attempt, still using much of the code from the first try. The process "works" now, with a myriad of workarounds and hands-on management required. If this organization didn't have big pockets, someone's head surely would have rolled for such mismanagement.
After having participated in this fiasco, anyone can readily understand why this IT organization's internal applications are absolutely terrible.
The problem is that management calls for it, IT in good faith builds it and by the time it hits the ground it's doomed for failure. Let's be honest most people in management have no clue about life at the operational edge and make assumptions about what the world looks like. A gentleman called Von Clausewitz once said the best laid battle plan does not survive first contact with the enemy. It's the same for IT.
You have to build from the bottom up and you have to stay flexible. You can't build perfect. First fix the main problem then tweak until as near to 100% as possible. It's not a build once and done, it's a constant process of adjustment to meet changing conditions.
You have to build from the bottom up and you have to stay flexible. You can't build perfect. First fix the main problem then tweak until as near to 100% as possible. It's not a build once and done, it's a constant process of adjustment to meet changing conditions.
those projects labelled as Business Process Improvements.
You could say the same about any change to any part of a business where there's a significant lack of buy in across the business.
It was the CIO's fault? Really? It was IT's fault, really? Substitute any top boy and their department.
That could only be true, if there despite there being no buy in, and because there was no oversight, IT went off on one.
Or if the resources were inadequate, or became inadequate and that wasn't recognised because there was no oversight, IT started and or kept going.
Or if the bunch of incompetents that were hired because they were cheap, were unfamilliar with the term scapegoat.
Alignment isn't IT employing psychics to try and figure out where the business will want to go despite not knowing they will yet.
It's recognising that we are one busines, one team, with one goal, and if we don't communicate (takes two !!!) , we'll both be scoring at the wrong end.
Another consultant telling business leaders what they want to hear, not what they need to. Still you get paid that way eh?
You could say the same about any change to any part of a business where there's a significant lack of buy in across the business.
It was the CIO's fault? Really? It was IT's fault, really? Substitute any top boy and their department.
That could only be true, if there despite there being no buy in, and because there was no oversight, IT went off on one.
Or if the resources were inadequate, or became inadequate and that wasn't recognised because there was no oversight, IT started and or kept going.
Or if the bunch of incompetents that were hired because they were cheap, were unfamilliar with the term scapegoat.
Alignment isn't IT employing psychics to try and figure out where the business will want to go despite not knowing they will yet.
It's recognising that we are one busines, one team, with one goal, and if we don't communicate (takes two !!!) , we'll both be scoring at the wrong end.
Another consultant telling business leaders what they want to hear, not what they need to. Still you get paid that way eh?
Ive been at this 30 years and the story has not changed. Fundamental mistakes will always end in failure.
If you or the lead know the project will fail, why change ? the reason simply show that you have no ground to make the change, so how will it be successful ? no matter how many years of experience you have and millions of methodologies, a failure is a failure.
The more IT lead, the more problem will occurs, try to put a non-IT staffs to work as IT that gives you more problem then it solve, beside IT should just be a department that helps business to apply and advice. Not and never be the one to make decision. I still prefer they call it Computing, so you only need to concentrate on computer stuffs not the business decision.
The more IT lead, the more problem will occurs, try to put a non-IT staffs to work as IT that gives you more problem then it solve, beside IT should just be a department that helps business to apply and advice. Not and never be the one to make decision. I still prefer they call it Computing, so you only need to concentrate on computer stuffs not the business decision.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
