When is an IT project not an IT project?
-
This may be a bit of a rant but it's something I'm trying to think through, so any feedback would be appreciated. I know most of your are pure IT and don't get involved in other aspects of a company's business, but some of you do.
First, the background:
My company has recently started a project to replace our existing, old ERP system with Microsoft Dynamics NAV. Two key reasons for doing this are to improve the efficiency of our backoffice operations, partly through streamlining our business processes, and to integrate other areas of the business into our ERP system that are currently using paper-based or stand-alone solutions.
This project was my idea and initiated by me, but now has full board support. I'm Project Manager, our CEO is Project Sponsor, and we have a permanent project team of around eight. I anticipate pretty much all staff will have some involvement in the project at some stage. I've split the project in to two phases, each of which are expected to last a year. I intend to go live with the new ERP system at the end of phase one, and at the point the old ERP system will be retired. I hope to devote around 80% of my time just to working on this project, leaving 20% to manage the rest of the company's day to day IT.
The problem:
I've been involved in these kinds of projects all my life. Probably the biggest problem I have faced is getting other non-IT team members to commit their time and effort into making the project a success. And I believe one of the biggest reasons they don't commit is because they see the project as "an IT project". I've been begging the board to see this project as "a business project", with a relatively small amount of IT.
I also don't think people understand my role as Project Manager. I'm not in charge. A lot of my project management work will be administrative rather than strategic or tactical. I have no power over other team members. Ultimately, the CEO is the only one that can ensure people commit and meet deadlines. I need to ensure the CEO has skin in the game so that he'll take action if he sees the project might fail.
I think these kinds of projects have become less IT focussed as the years have gone by. That is because they've reached a level of maturity and reliability that means they pretty much run straight out of the box. There aren't really any bugs in a modern Microsoft ERP system. It is isn't going to crash. Everyone has access to really good documentation and training. It used to take a couple of days to install a new ERP system. I could probably install Dynamics in under an hour and that includes Windows and SQL Server. But people still see it as an IT project that is of little concern to them.
Some people will commit. They'll read the documentation. They'll watch YouTube videos. They'll write a detailed specification for any changes they'd like. They'll come up with suggestions and ideas. They'll prepare for meetings. And they'll review their current business processes and look at ways of improving.
Others will just say "I just want it to work like our current system. I'm too busy to help you. Just show me how it works when you're ready to go live. Oh, and if it doesn't work just like our current system I will go apeshit on you and call the project a failure."
They might say, "So, how do you raise a sales order in Dynamics?". To which I feel I should reply "I have no idea. Why don't you figure it out?". Because what they're really saying is "I can't be bothered to figure any of this out, you do it and then let me know". Only that will result in project failure because I simply don't have the time to do it all on my own. No-one could.
Getting non-IT people to engage in what I would call "business projects" and what they would call "IT projects": that is what I'm struggling with. My first step is to persuade the CEO that this is definitely not, and should never be, an "IT project".
Discussing this with my wife last night over a drink, she said "You normally need to address these problems using either the carrot or the stick. Your problem is you have neither a carrot nor a stick". To which I replied "More wine?"
-
Wow. Ok, first thing I would do is not put the training off until the new ERP is in-place or even right around the corner. The time to start training is NOW! If you've considered all your possible ERP solutions and NAV is your chosen solution, you need to get the CEO to start building training time into peoples' day. Half an hour here and an hour there over a few months to a year that is consistent is much better than 8 hours or whatever all at once.
Also, to make the transition easier, I'm sure there are companies that offer training classes on NAV. To make sure your users are as ready as possible, have you talked to the CEO about procuring their services to train the staff so YOU don't have to? Are there going to be little questions here and there? Yes. But what you want to nick in the butt before it ever happens is the initial panic of "OMG THAT BUTTON ISN'T THERE AND I CAN'T DO THIS AND THIS THING IS NOW THERE AND THAT OTHER THING IS AWOL!" Mitigating panic on the end-users part that they can't do their job anymore is crucial.
-
The first thing is getting the business involved. If the business (the CEO, management, etc.) aren't interested, why are you? This seems like an organizational problem. Why you, as a PM and not as IT, are seen as IT and the project as one that people don't need to care about is the core of the issue and I can only imagine that this is a top down disinterest in the project.
I would present it as a business problem to the CEO and ask, if it isn't for the business, why spend the money to do it at all if it isn't important?
-
I do agree that from a technical perspective this isn't a super-complex project. You need to setup Dynamics, setup SQL, maybe make a GPO to place a shortcut on everyone's desktop, and import the old ERP data into the new system. The biggest trick is getting users to move to the new system, and that is entirely a business concern, not an IT one. One of my favorite quotes comes from Benjamin Franklin who said that "an ounce of prevention is worth a pound of cure". Prevent problems by proactively planning pain points and get things in place ahead of time. Now would be a great time to also think about maybe spinning up an internal KB for the new program. Find out common tasks people do in the current ERP, as well as things that will be done in the new ERP. Then, once you can, document procedures for placing a new order, inputting materials on an order, etc. Get people in the habit of checking that internal KB and have them make recommendations for things they'd like to see or, even once the current people are trained, things that would help a new person signing on at the company.
-
@scottalanmiller said:
If the business (the CEO, management, etc.) aren't interested, why are you?
Self-interest
This seems like an organizational problem.
Pretty much everything comes down to an organisational problem.
if it isn't for the business, why spend the money to do it at all if it isn't important?
I know some of you are familiar with Goldratt's Theory of Constraints. He wrote a book in the nineties about ERP called "Necessary but not Sufficient". What he meant by this is that we need a new ERP system if we are going to improve our efficiency (ie a new ERP system is necessary), but the system will not improve efficiency on it's own - we need to change our business processes (ie just buying the system is not sufficient).
I think CEOs in general underestimate how much people are motivated by self-interest and not by the company's interest. In my case, my self-interest (to implement IT solutions that facilitate improvements in business efficiency) aligns with the company's interest.
For other managers their self-interest might be, for example, to employ as many staff as possible in order to massage their fragile egos. This isn't compatible with our ERP project.
Some managers self-interest might be to reduce their workload so that they're not working ten hours of unpaid overtime every week and they get to see their kids more. This is very much compatible with our ERP project and I love working with these managers.
ERP is always a tricky project because however much you talk about increased efficiencies resulting in business growth the reality is that jobs are at risk. People aren't stupid.
-
This isn't just ERP, but any project that affects the business as a whole.
It sounds like you have management buy-in, otherwise why did they approve this project?
I'm Project Manager, our CEO is Project Sponsor, and we have a permanent project team of around eight.
So who's the project lead? Without one you'll almost definitely fail. In this situation the project lead needs to have the authority to mandate things be done. And if they don't have the direct authority, they need to have the close ear of whomever does have said authority.
Good luck, I definitely am interested to hear about your project as things go along.
-
@Dashrender said:
This isn't just ERP, but any project that affects the business as a whole.
Oh, absolutely. I always struggle with cross-departmental projects. Life get's complex when you have to involve other human beings.
I've been involved in loads of different projects, but usually projects are born out of some specific need, like the old software becoming unsupported, or a company merger. This is the first time I've gone "hey, let's rip out our working, fully-supported system and replace it with something completely different", which adds certain pressures.
-
But if you're not the project lead, then the success or failure of this project doesn't lie on your shoulders, even though it was your idea. right? So it's really up to the project lead to present it to other departments as a company project (aka non IT project) so they get the needed buy in?
-
Correct. I'm not familiar with the term project lead, but I'd guess that that role will (hopefully) be taken by the CEO, as he is Project Sponsor. My boss is also on the team and as Finance Director he has considerable authority over all the other team members.
I try and inspire the team, and provide some vision, which is kind of the "carrot" approach. But there will always be situations within any project where the stick is required, and that will have to be provided by the CEO.
-
@Carnival-Boy said:
ERP is always a tricky project because however much you talk about increased efficiencies resulting in business growth the reality is that jobs are at risk. People aren't stupid.
What jobs are at risk?
-
@scottalanmiller said:
What jobs are at risk?
Mine, for a start.
New business systems can increase automation which puts back-office jobs at risk. That's true generally and is not specific to my organisation.
-
@Carnival-Boy said:
@scottalanmiller said:
What jobs are at risk?
Mine, for a start.
New business systems can increase automation which puts back-office jobs at risk. That's true generally and is not specific to my organisation.
In theory, sure. But how does back office automation reduce, rather than increase, the need for IT to run the automation?
-
Possibly. It's probably a combination of automation and simplification that I'm striving for. Make our business processes so simple and automated that a chimpanzee could maintain them. At that point the company might decide that it's more cost effective to replace me with, you know, a chimpanzee.
More likely, the less complex you make your systems, the easier and more cost effective it is to outsource IT.
I'd actually like to reach the point where I feel I've achieved everything I possibly could at a company and I have to move on. Like the Littlest Hobo walking off in to the sunset in the TV series I used to watch as a kid. I doubt it will ever happen though.
-
It's tough to cultivate buy-in from other departments sometimes, you have to find their "hot button" and exploit it.
Example: Customer service mgr is paid bonus to reduce wait time; "hey CSM, want to make bonus easy? train your dude(tts) on this software"
-
Yes, money is a great motivation, as I often point out to my bosses.
When I mention this people often mention Maslow's hierarchy of needs. But I find people who believe in Maslow are normally people with plenty of money already.
-
Peter Taylor has listed the 6 typical phases of projects in his book "The Lazy Project Manager". They sound about right to me!
- Enthusiasm
- Total confusion
- Disillusionment
- Search for the guilty
- Punishment of the innocent
- Reward and promotion of the non-participants
I'm obviously trying to avoid the above.
-
@Carnival-Boy said:
Peter Taylor has listed the 6 typical phases of projects in his book "The Lazy Project Manager". They sound about right to me!
- Enthusiasm
- Total confusion
- Disillusionment
- Search for the guilty
- Punishment of the innocent
- Reward and promotion of the non-participants
I'm obviously trying to avoid the above.
Sounds like he spent time in a Government job.
http://agilemindstorm.com/wp-content/uploads/2011/06/Dead-Horse-Theory.jpg -
AWESOME!
