jump to navigation

How to Decide on Customizations 05/13/2009

Posted by TBoehm30 in Software.
Tags: , , , , ,
add a comment

Customizing your new software is one of the dangers that can lead to the project spiraling out of control. Too many customized changes or changes that are too complicated will alter the schedule, bog down the staff with work, and lower moral.

I worked with a company that installed a new CRM system with only the vanilla, out-of-the-box screens. The software had great tools for customizations and allowed all sorts of changes without affecting the license, or even the upgrade process. If the company followed the rules, then the upgrade process would take into account the customizations, and not cause problems. The company decided not to allow any requests for changes for the first 3 months.

This turned out to be a terrific rule. Many of the users complained because the system didn’t look like their old system. They weren’t sure what to do when problems occurred. During those 3 months, the users got used to the new system. They figured out how to solve their own problems. They found the workarounds for any issues that were serious enough to change their process.

After the 3 months were up, the changes started coming in. Those changes were well thought out, and would provide value to the business. The changes requested were the kind that IT could get working on, and wouldn’t hinder existing projects. They had new timelines for the new projects, so nobody felt like they were falling behind. The budgets were identified separately for the new projects, so no projects were over budget.

The IT department looked great because their large software project was successfully completed on time and on budget. They surveyed the business managers to find their satisfaction with the project. They got high marks for their project management abilities and their ability to get people working on the new system. The new requested changes would be worked on with full approval from management who have faith in their IT people. This confidence was gained through successful projects, and satisfied users. What a great working environment this was.

I have also worked on projects that were overwhelmed by changes. Our weekly status meetings showed that we should be aiming for a moving target. The work we had finished the previous week was now obsolete and we had to start over. Some of the requests (in our opinion) were absolutely ridiculous. Some of them were most likely submitted for the sole purpose of sabotaging the project. Many of the users were very afraid that the new system would make their job much harder. We ended up scuttling the project because we had no chance for success.

Somewhere in the middle of these two extremes has to be a good model. Users will have legitimate changes to a project while it is underway. Sometimes the project managers won’t have thought of all the consequences until users start testing. Sometimes the users don’t understand the consequences of their changes. Sometimes neither side will understand how complicated it becomes to change large software systems.

The takeaway – create a process to evaluate customization requests for your software. Understand the costs and the benefits of those changes before deciding on if and when to implement. Remember that it’s a global world out there and technology makes it happen.

Advertisements

ERP Implementation Obstacles 03/24/2009

Posted by TBoehm30 in ERP.
Tags: , , , ,
1 comment so far

The Struggle
Your ERP system is chosen. Management has spoken their approval and you have the team together. It’s time to put together your plan. The first real item on the plan is initial training. This is the type for the planners, not the end users. It’s just to learn the system enough to put together the implementation approach. In this particular case it’s the strategy of accounting vs. manufacturing. What parts of one or the other can we use to phase in the project. As I said in a previous post, I don’t like the big bang approach.

We need to schedule the accounting training for the accountants. These are the same accountants who close the books every month. They are the same accountants who prepare the books for publication every quarter. These accountants, by the way, spend quite a bit of time closing the books. That is the main reason why the company needs an ERP system. They need a better way to consolidate the books.

So when can these accountants take time away from their busy day jobs to work/train on the new ERP system?

The Problem
The company runs very lean. They have just enough employees to get the job done. Everyone has their job, they know what they do and they do it very well. However, it is not automated. Their jobs could be much easier with some good technology. An ERP system with a single database would allow corporate accounting to easily consolidate their books. They will also get better insight into the costs of the business and be able to make better decisions. They’ll be able to understand the costs of producing different products. They’ll have better insights into their inventory and holding costs.

The first new task to start the implementation is training. When can we start the training? It is now the end of March. That means the end of the quarter and all of the work associated with closing the books. April is ruled out.

How about May? April books need to be closed, so maybe the second week of May. It seems like we’ve only got the accountants for half the month or less. That is not going to be enough time to complete an ERP implementation in six months.

The Solution
Once again, we need Executive support. It takes decisions at the highest levels to pull people off of their current jobs and get them to focus on the new project. This project has to be the number one priority. The only way to set that kind of priority is for a CFO or C-level Executive to set expectations.

They’ll also need help, probably from the outside, to continue normal operations. They’ll need to hire temporary workers who have enough skills to close the books. They’ll even need help from their current departments to continue operations while some of their leaders are working on other projects.

This is a short term headache to create a long term positive change for the company. Will they have the strength to pull this off? I think so because they are very aware that it’s a global world and technology makes it happen.

Almost There 03/11/2009

Posted by TBoehm30 in PMO.
Tags: , , , , , , ,
add a comment

The PMO is still not out yet, but at least now I know the issues (I think. (I hope.)).

The IT director has talked to the CFO to find out that it is still a power struggle. The PMO (Project Management Office) cannot be given too much power because decisions will still be made at the highest levels. His concerns are that people will think that all decisions, not just the ERP project, are being made by the new PMO.

OK, we can easily word the announcement (read previous posts) so that it is obvious that this group is responsible for 1 project. Yes one project only. They are not taking over the company. They won’t decide who to layoff, or who to promote. They won’t change the manufacturing schedules. They are being created as a cross-functional team to oversee the very large and complicated implementation of the ERP system.

It turns out that the CFO has been working pretty hard lately. He actually, really, hasn’t had much time to think about our needs (really). This is a pretty good thing for him to realize because when the project starts going he knows that he won’t be, nor does he want to be, the guy making all of the decisions. The PMO will be making plenty of process decisions to successfully implement the ERP. They need to be empowered to do that and only that. Our newest announcement will grab power for that singular purpose.

The other issue is the board of directors meetings. He is going to talk to the leaders of the company separately about the new PMO. That is good news. That means that the higher ups will already be aware of what is about to happen and can support us when needed. He wants his ‘official’ announcement to go out after he has had a chance to talk to the board. OK – good issue, didn’t know that.

We are also going to include text in the announcement that specifically states that the PMO has been setup for this one ERP project. If this one project goes well, if the structure of the PMO enhances the value of the implementation, then they may continue it. The future of the PMO will rely on their own success.

The PMO announcement still hasn’t gone out. The CFO will be meeting with the board some time next week, so we are still in a waiting mode. At least now I don’t have to be thinking about strategies for overcoming our very first obstacle. I’ll give it one more week before I get frustrated again.

That is fine with me because I know that it’s a global world out there and Technology makes it happen.