We have definitely been here before!

We are rapidly approaching the point for our overseas site to go live – they are due to start using the SAP production system starting on the first working day of the new year. As we only have a few days left before Christmas, there is not a lot of spare time.

The data loading process has been going on for some time now - I asked about how they were getting on a while ago. I was told that it was all done – but when I pressed a bit harder, it was admitted that there were a few items not quite finished. (Such as bank details, purchasing info records, part of the master material, some of the customer’s data and some other equally inconsequential items!) The work to load this is still going thru, but I would not be surprised to find it incomplete on day 1 of their go-live.

It also has to be said that there are still some items that have yet to be configured. Two weeks ago, it was agreed that we would stop all further changes in order to concentrate on the data load. It was suggested that I would do any further role change requests, as this could be arranged at a time when there would be no issues with processing the transports (as it happens, there has been no need for this). However, one of the consultants apparently didn’t get the message – a change was made, pushed thru without reference to anyone and a whole day was spent undoing some of the issues created.

In the mean-time, the SI has sent a letter of complaint that caused some internal discussion. There are a lot of bills that they have submitted that our FD simply will not pay. Of these, more than half are for work they say was done, but that we have no evidence for. For example, they had a person on site for several days over a 3 week period according to one bill, but the person concerned had left their employment and was working in a country on the other side of the world on the dates that they supplied. There have been items for 100s of miles of travel and a night’s accommodation for the same day.  Just to really stick the knife in, they also changed the agreed daily rate billed on some of the items – and when the FD asked who had authorised this, they were unable to give him an answer.

Over the past few months, I have also been trying to look at ways that we can make more use of our SAP system. It seems to me that whatever I might think of its capabilities and shortcomings, having spent as much money on the project as we have, we should try to make sure that we get the most bang for our bucks. There is a specific process that one of the managers has been wanting to do for several years, and altho I have a few concerns about it, it seems that this could be done within SAP. Part of the work is already done, which is a plus – it would just need slightly more data being entered than before.

His concern (and it is a valid one) relates to the output – he wants to do specific things with that, and it was subsequently suggested that it could also be used to improve some of the data provision to customers. These are all very consistent with company strategy and I want to encourage him. However, there are some concerns about how it would be done, and at present we don’t yet have the necessary specific skills internally – this would then require we buy in more consultancy.

Because of those concerns, he has recommended that we look to buy another software product – and to me, this is just utter madness. He wants the company to allocate another $300,000 to fund his project, but what really bothers me is that it would then duplicate the work being done, require more hardware, more software (plus licences, maintenance etc.) and he’s suggesting that it could be at least a year before the project would have any output worth using. Color me crazy, but that does not seem like the best way forward when we have already paid as much for SAP as we have, and could do the job as well by spending a little more on getting some training done.

So – the holidays are nearly upon us. Decorations are up, the tree is dressed, presents are wrapped, parties are being organised. We seem to have enough food in the house to last for the rest of the winter – I’m told that we are inviting lots of friends & family around this year and we must of course provide hospitality (I don’t remember having THAT discussion!).

As this will be my last post for 2011, I would like to wish you all a very merry Christmas, and I hope that whatever the holidays mean for you, that you enjoy them in the company of your friends, family or loved ones - and may the New Year bring you all the success that you would wish.

Back to the training board

I've not posted anything for some weeks - mainly because I've not really had anything to add. Work continues as normal, but there has not a great deal happening with our SAP project.

The go-live date for our overseas site was put back to January of next year. This should have given us time to get some of the data load done, but very little has been added so far. We still have time, but we are still waiting for much of the data, which is still to be cleaned up. However, the staff at the overseas site have actually been doing some training, and they have also been testing what data has been added, as well as manually adding some data of their own. I think that this will be very useful as it means that they will be more comfortable once they start using the system for real.

One thing that has been discussed in some depth is an old favorite of mine - training. I've said a number of times that I feel we should be enhancing our internal skills by getting our project team members and perhaps even some of our end users to attend formal SAP training. To me, it makes sense to invest the money in our staff, and retain knowledge within the business, rather than pay consultants who will be here today, gone tomorrow.

The costs are pretty straight forward - pay a consultant $1500 per day, or get staff on a 2 day training course for about the same money. I'm not sure how many times I've discussed this with people - probably to the point where I get boring. But I've been on some courses, as have some of my staff, and we know the value of the training, and can demonstrate the benefits.

To me, it is so simple - and yet our project team haven't seen it that way. I believe that part of the issue is that I am used to the idea of continuous training - anyone in IT will know the value of this and the need for constantly renewing skills. On top of that, I am also used to the requirement of managing my own training - but clearly, this is not how others see it.

However - it seems that my message is slowly starting to sink in. I've recently had a number of members of the team speak to me about organising training, and it seems likely that they will now carry this thru. The only problem is what courses will be of the most benefit and how to make sure that they get the most from the courses.

I am aware that if they attend a course and it doesn't meet their expectations, they will be less likely to want to go on another. I'm therefore trying to make sure that we have a very clear roadmap of the appropriate modules for each individual. I'm not so sure about the need for some of the certfication tracks - I don't consider it necessary that we need to get people qualified, but we should try to make sure that the plans follow a pattern that will provide appropriate knowledge in each area.

One thing that has been noted - the project team members are a bit more vocal in the way that they describe the lack of knowledge transfer from the consultants. They also seem a bit more prepared to criticize the quality of work carried out, and several of them have highlighted key areas that they want to cover in training that have been those where the consultants did not achieve what was required. I'm not sure that we can do this straight off, but I don't want to put them down too quickly - I'd rather try and keep their new enthusiasm high for as long as possible.

I suppose that once one of them goes on a course and then comes back and can confirm to the others the value of what they have learnt, we will then see a sudden rush of the others - well, that's OK as far as I am concerned. We have a decent sized budget now for the training as long as we can continue to justify it, so I want to see it used to best effect.

Hopefully, I'll have some feedback from at least one of them soon.

Have we been here before?

So - we were supposed to go live at our overseas site today. Up until Wednesday of last week, they were still determined that it would go ahead, come what may. This was despite no more than 10% of the data having been loaded, and we are still waiting for quite a bit of data to be extracted from their legacy system.

I only finally got the confirmation of the delay midday on Thursday - it's been put back to December at the moment, but I'm not sure if that will stand either. I know that the site manager is relieved as he was really concerned that they are just not ready, and I believe that most of the staff there are equally pleased. Our project team are not entirely happy - but they all accept that it would be too much of a risk to try and go ahead.

Now we have a bit more time to try to resolve some of the issues that are still outstanding - but I'm a bit concerned that we may end up with a few more as well. There have been a couple of config changes made and once again, it has caused us some problems. (Did someone mention testing?)

This time it's the purchasing, which is a real pain as that has actually been pretty good for some time now. It appears to be to do with the release strategy - the change means that staff can release purchase orders to any value, instead of the staged release which took us about 3 months to get right. I left the manager in charge of the purchasing department working his way thru a number of items to try and get a handle on exactly where it has gone wrong.

The consultants fixed the printing problem on the purchase order - well almost. There's a bit of an issue with the vendor addressing and a number of the POs have completely the wrong details. I got a message earlier today to tell me that there is a specialist going to take a look - it appears that he has already had access to the system, but he's been using someone else's account. I've now created an account for him, and asked him to use that - I've had no response, so I don't know if he hasn't received the message, or just can't be bothered to do so.

There was also an issue on the finance side (not quite sure what it was) and they had arranged for a consultant to look at the problem - we were told that it would take them about 4 / 5 days. However, the FD was looking at it, and with the help of a Google search, he has fixed the issue. The SI are not pleased at this.

Talking of the SI, I've had one of their people chasing me to outsource the systems to them. This is something that I'm not particularly keen on for a number of reasons. They insisted that it would all be managed in a facility in this country, but when I checked, the data center they use is actually somewhere else in the world - I think it might be either eastern Europe or Malaysia, I've not been able to clarify.

Their sales guy insisted that it would be cheaper to use them - well there would be savings in hardware / software / utilities, but I doubt very much that it would work out any cheaper. Some time ago, I looked into the costs, and based upon what we would need, the price from the only hosting center prepeared to give me an estimate would indicate that we would be looking at $300,0000 a year now, rising to $600,000 in about 3 years time. I can tell you, that would be more than our current IT budget.

However, it's not just the cost that worries me - this system is going to be the key system for the whole business. A decade ago, it wouldn't have mattered if it went off line for a few hours or even a day or two - that's not the case now. Quite simply, a loss of service of more than a few minutes would be problematic, more than a hour could be disastrous.

Based on their performance, can we trust our key system to them? Of course, it's not just the potential loss of service. I don't feel that they have demonstrated that they work in a particularly secure mananer, and I'll be honest, the thought that they might lose data scares the heck out of me. However, it won't be my decision anyway - this is something that the board will decide. Apparently, they are arranging for a junket at a country club for the shareholders and the board, to advise of them how it would work - I have not been invited.

However, I have been asked to put together a presentation of my concerns, highlighting the costs. I've also included some statistics on what we have achieved and how much we have saved by doing it all inhouse. In addition, I've put forward some plans for future development that would allow us to ramp up the resources to deal with required increases as the other sites come on line. We'll see what happens.

Back overseas again next week. I'm really racking up the frequent flyer miles - next time, I'm taking my wife with me!

I'm Back!

I’m back! Before you ask, I had a great time thank you.

Unfortunately, the flight back was delayed – and we got home very late on the Sunday. There were a number of messages waiting on the ansafone (I hadn’t taken my cell phone), and essentially, the messages all said that I was to get over to our overseas site asap. So I packed a fresh suitcase, and got my flights booked – with an early flight, the time differences plus the delays the day before, I was really very tired by the evening.

I spent the week over there, and then it was decided that I should go back again this last week. What with that plus trying to do my normal work and various other chores, this is the first chance I’ve had to sit down and analyze the situation.
I’ve not been told officially, but it appears that a number of staff have been told that the overseas site will not be going live in October after all. I’m not surprised – the data load was supposed to have started the 1st week of August and it hadn’t started by September. Even now, very little data has actually been loaded, and it appears that there are still some unresolved issues with parts of it.

During my first week over there, I spent a bit of time doing some training – about half of the staff there had still not even logged onto the test client, and they are a long way from being confident in using SAP. I also had a very upset General Manager complaining that there was a printing problem. When I checked, it was actually only one document that had the problem – the sales order form, so rather important that they gets this fixed.

I haven’t done that much work on the smart forms, but I took a quick look, and discovered that one their consultants had made the change. Unfortunately, no-one knows why or what for, and the guy isn’t available. I’ve left it to them to chase up, but so far, it’s still not printing at all.

Another issue has also appeared recently that affects the financials. At first, the consultants suggested that it was an authorization problem, but we’ve now identified that certain products are being assigned to the wrong ledger code. Again, no-one is really quite sure why – we have our consultants telling us that the configuration was correct, and their consultants are saying that it’s not. So they’ve made a change and now we have a problem.

Our Accounts Manager is really upset about all of this. A couple of times now, she has spoken to me in private, and it’s clear that she is very distressed about the whole scenario. She’s been with the company a long time, and has been thru some really tough times, but I think that this is the worst she has ever felt about her job. I just don’t know what to say to her anymore.

I’m also a bit concerned about the amount of testing that they have done. If you’ll remember, a bunch of us went over back in April, and we did some full end to end testing of processes and made sure that everything worked – but that was only using a limited amount of test data.

The guys on site have access to the test system and although not all of the live data has been loaded, about 80 – 90% is available. But the testing that they have been doing is not the same end to end testing. Yes they have put a whole ton of quotes, purchase orders, sales orders on the system, but they have not then followed this thru to make sure that orders appear on the MRP or that sales get billed.

It could be argued that we shouldn’t need to test again, as it was proven to work in the development system and we are using the processes in the production system. But the issue is that their consultants have made a few changes and I strongly feel that we can’t be absolutely sure that any of their tests would actually work unless we do try it out.

I did manage to speak to the GM of our overseas site one evening over a beer – he is very much of the opinion that they will not be ready for the start of October. He did suggest that perhaps they could have a staged approach to the go-live, perhaps by working in tandem on both systems. I wouldn’t have a problem with that in principle, but they don’t have that many staff, and I’m not sure they could actually do that.

Oh well, back in to work tomorrow, and maybe I’ll find out a little more about what the plans are.

Problems with prices

About 4-5 months after our go-live, I received a request for a change to a role. At that stage, we were still making quite a few changes as we discovered issues that had not been uncovered during the testing phase. This was quite normal, but something about the request didn’t seem quite right.

The particular role was one that I had worked on with the sales manager, and the request from our second site seemed to indicate that there was a problem that should have affected everybody. When I went into it in more detail, I wondered if it was due to the staff concerned not entering the correct information.

I passed this back to the relevant key user from sales, and she confirmed that the process was working for each site – it seemed that this was an issue with staff training. So the sales manager organised a quick refresher session with the sales staff at the second site.

Whilst he was going thru this with them, he also spotted an issue with the cost price of one item that they were using. Quite simply, the cost price shown in SAP was way out – in fact, even with the price uplift, they were actually selling the item at a loss of about 25c each for a selling price of just under a dollar. He then started checking a few other items – most were OK, but there were more than a few with a price that was wrong.

Subsequently, they spent some time going thru the rest of the price list to make sure that this was OK – and based on what he found, the second site had lost just under $10,000 in incorrect pricing during those first few months due to an incorrect price having been loaded during the data load process.

An investigation proved that the price had been wrong in our old system. At some stage, the price had gone up but never been altered in our old ERP system. No-one knows how much we lost in total, but most agree that it’s probably over $25,000 for each of the previous 4 years – a total of at least 100 big ones. You can imagine that there were some people that were very unhappy about this.

The reason I raise this now is that we were doing the training with our overseas site just over a week ago, and it appears that they also had the same incorrect prices in their old system. This has caused some real upset as people are trying to uncover when things went wrong and why. I doubt that we will ever know.

Of course, one thing we can say is that is not down to SAP. The problem occurred long before we started the implementation. It could be argued that this should have been picked up at the data cleansing phase, and that’s probably true – but it wasn’t. No matter what anyone thinks of the software, there is a limit to how much it will cope with the failure of the human element.

So chalk one up for SAP – while the correction of the price won’t cover the costs of the software, it’s identified a major problem that has taken money off the bottom line, and one that would quite possibly not have been discovered for many years. Although there are still questions about getting an ROI for the project, each of the areas where it has made a difference will help to justify the decision to buy it.

Oh well, vacation time is here. I feel that it is overdue, and am looking forward to a good break.

None so blind...

I started to write this item a couple of weeks ago – but didn’t finish it at the time. I was highly annoyed and wanted to think about things before posting.

We actually started work on the SAP rollout at our overseas site almost 2 years year ago. However, nothing was ever completed, even in the development system and eventually, the project stopped before being started again with a new set of consultants in the middle of last year. The plans then were to go live at the end of October last year – as the previous consultants had done quite a bit of work, it was felt that this was achievable.

However, it quickly became clear that most of what had been done was of no value. Essentially, it all had had to go right back to the very beginning. The SI were still trying to say that October 2010 was achievable, but most people on our project team could see that was never going to be possible. A date was set for the end of July this year – most people agreed that this could be done if all went well.

As it happens, in April of this year, the consultants still had not finished working on the development system. We also had issues because almost no testing had been carried out, and absolutely no training had been done either. Our project team then went to the site to do some work, and as I’ve indicated, we managed to get a great deal done. So much in fact that we all thought it might still be possible to go-live in July. There is still major work being done by the consultants, but from experience, it seems to be normal for them to still be working on items right up to (and even after) the go-live date.

But there has been a major problem with getting data loaded. First getting data out of their existing system has proven to considerably more difficult than anyone believed would be the case. Cleansing the data was also a bit of an issue – but the biggest problem has been getting it matched to the relevant data load into SAP. I had been told by the SI that about 80 - 85% of the data load had been completed into the development system – but during our test phase it became very clear that it was really closer to 10 - 15%.

Since then, some data has also been loaded into the test system – but no more than about 30 – 40%. Some training has been done with key users, but none with the rest of the end users. I had to go over there again a few weeks ago, and they were trying to do some testing work in the test system. Most of this failed simply because there was insufficient data to allow more than few test scripts to be used – it took them as much as half a day to complete a single test item.

As it became clear that July was slipping away, a decision was made to move the go-live date back yet again. This makes sense, and I have no issue with that other than once again, we are committing many resources to the project than was originally planned. But what has outraged me is a decision that has been made following further discussions with the SI.

The director of the SI suggested to our senior managers that we did not need to complete the data load process in either of the development or test systems, but simply go straight to the production system and load the data without having to do any testing. The argument was that we had done a few items so that proved the process worked and therefore any further data added to the same process would also work. He also argued that if we needed to have data in the other systems, it would be easier to do a system copy after the go-live.

I tried to point out that this view was completely wrong – we have seen repeatedly that people make mistakes when preparing the data. In some cases, the mistakes are so significant that the data will simply not go into the database without considerable manipulation by the people carrying out the work. To trust that all of the data will load correctly just because you have loaded a few lines is at best, wishful thinking in my opinion. As far as I am concerned, completing the data load process in the development and test systems should then save time and effort when loading into the production system.

But there we are – I can do no more than point out the issues and then do my best to see if I can fix the problems when they occur. But I must admit that I am now really beginning to feel that I can do no more on this project. I feel so frustrated all of the time – all I hear is that everything is going well, when it is abundantly clear that things are far from satisfactory.

I have no problem people trying to maintain a positive attitude – I can see that sometimes this is a necessity. When something requires such a major business transformation as SAP, it is essential to keep everyone motivated. But what worries me is that we are seeing “ostrich management” – burying their heads in the sand in the hope that if they don’t see the problem, it will just go away. I can’t believe that will be any good for us, now or in the future, on this project or any other.

Eye of the beholder

Last week, I had the opportunity to visit the manufacturing plant of another company. These people started to work on SAP a couple of years before us, and I had been told that they had been successful – so I was interested in talking to them in a bit more depth.

I had the chance to talk to the IT manager on site – a nice enough guy, although he seemed a little distant. As we talked, he made the point that they had gone live after just 8 months and they had experienced no problems. I won’t say that he was being arrogant, but there was a definite sense that he was as far as he was concerned, their project had gone very well indeed, and he was more than a bit proud of that. When I told him of our project and how long it took, he made me feel a bit bad.

However, I also had the chance to their production guys, and they had a slightly different story to tell. A few days after go-live, the system had gone down, and it took a couple of days before it was working again. They didn’t know why, all they knew was that it caused a few problems for them. That was bad enough, but it appears the same thing happened on several occasions over the next 4-6 months. Added to that, it appears that they still have an on-going issue relating to some of the data that they are accessing – they couldn’t tell me why.

After that, I spoke to a couple of their finance people. They remembered the first few months as being a complete nightmare caused by a series of issues with billing documents, financial reports and figures just not adding up. It appears that most of these are sorted, but they still recall those problems and again, they are still finding issues on a regular basis.

Later when I checked, it seems that there is quite a difference between the size of the projects, even tho’ the companies are about the same size. They have a lot fewer products than us, and there was a lot less to do on data migration. In addition, they don’t use a couple of them modules that we are using – and these items were seen as being responsible for a good proportion of our delays. Possibly our project might not have taken so long if we had been in the same situation as them.

When I thought about it later, it seemed to me that this is a case that the individual people were really only concerned about what had happened within their own areas of the business, and the project had been judged by that. As far as IT was concerned, the project went well because it came in on time and budget – the other issues were irrelevant. But for the other departments, they could only see the issues that had caused them major problems. Even years later, they don’t see their SAP project as being that successful.

I was once told by a CEO that he liked me because I looked at the bigger picture, and in his experience, most people in IT just didn’t do that. I can appreciate that the IT manager in this case was pleased with the project and felt that his team had performed well – but I could also see that the other departments were not as happy and for valid reasons. OK, they did get things sorted, but it was clear that it could have been a lot worse for them. When I compare that to our project, I don’t feel quite as bad.

I think that with an ERP system, it is important that people look at it from an over view rather than just within their own specific areas. If I think back, it seems to me that when things weren’t going well, it was because it was a single person or a couple of people working on their own without involving others. When things went well, it was because we were working as a team.

I know that the SI have been telling people that our project was a success – and if you look at it from a particular perspective, they are probably right. SAP is working for us, and in some respects, it has achieved some of the primary requirements. From the company point of view, that’s not the whole story – the project has been very expensive and taken a lot longer than we had been told it would. In some areas there has been no benefit or processes are much more difficult – in other areas, we have seen improvement or there is an indication that we may see this in the future.

Essentially, it seems that the quality or success of an SAP project is very much in the eye of the beholder. Personally, I would rather judge on well it achieves the requirements stated at the beginning of the project – but then, that’s just my opinion.

Paperwork

Right back at the beginning of our project, I talked to the SI about the need to provide us with detailed information concerning what changes they had made to the system. To me, this is just good practice – any time that someone makes a change to a system, it should be documented. There are a number of reasons behind this – people are not always available to confirm what has been done, jobs change and people move, security and audit issues etc. so good documentation is really important, especially before you start making other changes.

The SI promised that we would have full documentation, and they did indeed send us a document once we had gone live. However, it contained almost no actual information on the changes made, other than some flow charts to show processes and was quite a small document compared to the work done. I queried this at the time, and was told that this was standard SAP documentation – when I pushed a bit harder, the guy concerned got really snotty with me. His view was that this was the same format provided to everyone else implementing SAP, and those people had no issue with it, so I should just accept it and stop complaining.

I spent quite a bit of time trying to see if I could find a way to uncover what config chnges had been done, but I must confess that with all the other work going on at the time, I simply could not keep track of what was happening. It also became pretty difficult to maintain details of who was working on what, when, why and what they did. We had an issues list, and for the most part, this is now our primary resource for determining what work was carried out.

As it happens, when we applied a number of support packages, we found several issues. After investigation, it was determined that some of these (not all of them) were down to config changes having been made, and this caused a number of delays until we could complete various work to deal with the situation. It definitely took much longer to do the updates than it should have, and the delays impacted other work.

However, about a year after we went live, we had another consultant on site for a few weeks. When he left, he handed over a really detailed document that we still have – it gave information on what he had done, what changes, what code even. The file was everything that we had previously asked for, and exactly what was needed. It ran to a couple of dozen pages, and was really helpful as we could then refer to it when there was a question about an issue a few weeks after he had gone.

As you can probably tell, I think that this is a very sensible and professional way to work. I raise the subject because there is a particular consultant that has been doing quite a lot of work on our systems, and a couple of weeks ago, we found out that he has now left the SI. The trouble is that he has documented nothing – and I mean absolutely zip. No-one at the SI can talk to the guy, and they have no idea of what he had done, or how far he has got with the work he was doing other than at a pretty basic level.

OK, we will survive – but it is not the best way of working. It’s just another example of bad practice, and when you are paying about $1500 a day, I think that you are entitled to expect a certain level of professionalism and I am not convinced that we’ve seen that from some of the people that we have had working for us on our project.
Having said all that, I would understand if anyone then turned the criticism back on us. The systems are ours, and it would not be unreasonable for someone outside of the company to suggest that it is our responsibility to maintain records of what work is done. As it happens, we do keep some records for various reasons and we can point to a number of audit trails that show we are attempting to maintain a level of control.

The problem is of course that in many ways, the SI and the consultants working for them were working in the way that they want to, rather than in a way that matched what we want or need. I suspect that for most of the consultants concerned, this is the same way that they have worked on all of their projects, and they know no different. Our project leader should have forced the issue (and he freely admits that) but he was taking advice from the SI on how the project should run. But we will probably never know all of the configuration that has been done.

Well it’s too late now – just got to keep going as we are.

No change here...

It’s been about a month since my last post – and there’s a simple reason for that. I’ve been really busy on other projects, not related to SAP. I’m not the only either – several other departments have also been catching up on various things that have been delayed.

We started the SAP implementation about 4 years ago. At times it seems astonishing how quickly the time has passed, at other times it seems that we have been working on it for ever. The problem is that during that time, so much effort has gone into the project, that many other jobs have been postponed. In a couple of cases, this has not been a good thing – we needed to get on and get them done so it was decided that we would do exactly that.

For IT, there have been a couple of hardware refresh jobs, replacing workstations, printers and a Xerox machine. We’ve also been testing a couple of tablets that we think might be of value to the sales force. There have been couple of jobs done within some of the offices to make more efficient use of the space available, so we were also getting involved in the cable work. As you can see, this has meant that there hasn’t been a lot of time left to do more than basic work on SAP.

After the last visit to our overseas site, everyone felt that we had gotten thru a lot of the outstanding work and had almost caught up so that we would be back on schedule. When we left, the point was made that they needed to get on with the data preparation so that it could be loaded. We had done some loading of a few basic data items into the Development system, but not all of the data, and literally only a few items in each category. A decision was made that we would load no more into the Dev system and just go straight thru to the QAS system.

I was a bit concerned about this, as I felt that the actual loading wouldn’t really take up that much time, and felt that it would make sense to try to get all of the data sorted and proven. However, I could see that we need to keep on schedule – I’m not happy about cutting corners, but I can probably live with this.

However, when the data arrived, it quickly became clear that it was simply no good. Not one of the data loading batch jobs was able to complete successfully, and most were so poor that we were looking at maybe 10-20% had gone in successfully on each batch. It was so bad that the project leader took another trip over there to talk to them again. When he arrived back, he was really pissed – he went back over the requirements with their people but feels that they still don’t quite yet get it.
I haven’t been asked if I would go over again, but I know that there have been discussions, and I get the feeling that they are expecting me to offer to go there in the next couple of weeks. As it happens, there is work that I was planning to do, but I’m not sure I will have time to do both jobs, the planned work and talking with them about the data preparation and cleansing.

There is no question that it is essential we get the data right. We found this out ourselves when it was our turn. We have made the point to the people at the overseas site, and several people discussed it with them, making the points very clearly. We provided some sample files showing how it should be done, highlighting the main pitfalls – but none of this seems to have made the slightest difference, and they are now well over a month behind where they should be, and falling further behind each day.

No-one has said anything, but I’m now a bit concerned that they will cut back on the testing in the QAS system before we go live. I’m also a bit worried that staff over there won’t get the full amount of training before their cutover. For me, it would make sense to push the go-live out again, and make sure that things are done right. But it seems that there is something going on in the background, and they don’t seem too keen to discuss any further delays.

Well, we’ll probably know a bit more in a couple of weeks’ time.

What a difference a day makes...

Or even a week…

Our project leader has been over to our overseas site a number of times so far this year, about once every 3 weeks or so - and altho he has said in the board meetings that things were going well, it was clear that there was a bit more hope than confidence in what he was saying.

Privately, he has been suggesting to the project team leaders that there are still far too many issues unresolved, and that despite quite a lot of hard work, we don’t seem to be progressing as fast as we should be. Although he wouldn’t actually say we were behind schedule, it’s pretty clear that the proposed go live date was looking increasingly hard to meet.

I’ve suggested a number of times that we should get the staff from our overseas site to visit with us for a week so that we can help them out with training and testing – by getting them to work with our staff I hoped that they would pick up some of the required knowledge. But altho it was seen to be a good idea, we have had none of their staff visit with us since last August.

It was then suggested about a month ago that we should arrange for our project team to go over there instead. Plans were made, travel and hotels booked and the project leader set out a plan for the week. This was primarily to test their processes to make sure that these would work – I felt that this would be a good start, but was concerned that we would miss a good opportunity to ensure that their staff was adequately trained.

I’d also gotten a bit worried about some of the comments from our project team – one or two had said to me that they were not really sure what they were supposed to be doing over there. So I made a point of spending some time with each one, to discuss how to test the various processes, and I set-up a series of test user accounts for them and made sure that they knew what they had to do.

On the first day at the site, we weren’t able to get much done – we arrived late in the day, and really only just managed to introduce ourselves to people, and get things organised so that we could start work properly the following day. But after that, things really started to take off.

The project team made a point of getting the key staff in with them so that they could see the processes, and in most cases after a couple of demos, these people were carrying out many of the actual tests. That second day, we had actually gone thru every single process and tested at least 3 variants for each. Their staff are now far more confident in the way that they use SAP, and altho they still have more work to do, based upon what they did last week, they should be ready for the go-live.

It should be said that during the tests, we did actually find several key issues – but about half of these I was able to correct almost immediately. As one of their consultants was on site, the rest were passed to him and it has to be said, he made a good start on getting them corrected. However, he also made contact with a couple of the other consultants and they were then available on the third and fourth days.

In fact, by the last day, we had not only gone thru every process many times and confirmed all were working, most of the outstanding issues had also been addressed. This included several that have been on the list for months. It also highlighted a couple of issues with data – I had tried to highlight this previously, and now it is obviously the most urgent major problem remaining so they are looking at dealing with this next.

It should be said that it was hard work - most of the guys were suffering with jet lag, and one had an upset stomach. It's also been a bit warmer there than we normally face this time of year, and some had difficulty sleeping at night. Despite these problems, everyone was really pleased - and I have to say that it is very clear that we have made a major leap forward.

We still have a lot of work to do, but we are almost back on schedule to go live in a couple of moths time. If we can get the data done on time next, then it should be possible to start the next stage of testing in the test system before the end of the month - and if it there are no major problems, we will be back on track.

It helps that there are not that many staff at that site and that they don't have to learn all of the various processes. But there is a lot more confidence now, both on site and in the project team. It has been said that it may be necessary to organise another trip over, and if we do, I'm sure that it will prove to be as valuable an exercise as this one was.

Learning the hard way

I got back late last night from our overseas site. The project lead and I made a trip over to check on how things were going, and to make arrangements for some later work.

The first issue was the cleansing and preparation of data. When we first did this for the initial project, we found that there were some key issues - getting the actual data extracted into a format that people could use, then getting the relevant departments to tackle the job of cleaning the data out so that we would have only good stuff to load.

We'd found that this was a lot harder than we had anticipated. Some of the data extracts from the legacy system were OK, but there were many areas where the different aspects of the data were not together in the old database, so it required some careful work and a lot of double checking in order to assemble the separate bits of data together. We made this point very clearly to the people at the new site - and gave them what we thought would be the right tools to help them.

Unfortunately, the extract has again taken a lot longer than we expected. In this case, they are dealing with an outside company on a system that we know little about, and the actual data only started coming thru about 4-5 weeks ago. They have been checking the data, but there is still a lot to do - the first couple of tests showed that they are not even close to having it ready for the full data load process which is supposed to start in 1 weeks time.

I'm not involved in it this time - one of my staff is doing the data load and I have virtually lost him for the next month whilst he processes the data. He is really confident and I'm sure that he will do it right - but I know from the work that he has done previously, that it will take more than just the next month to finish. He gets bored with things very easily and moves on to new stuff before finishing a job - I have to monitor him all the time and keeping reining him back in to make sure that he stays on track.

There is another concern as well - and it relates to the knowledge transfer process. I think that the big problem here is that several of the staff are still thinking in terms of how they do the various processes within their existing system. They then have got the consultants to show them how that specific process is done in SAP - and that is not the best way to approach learning the product.

When we first started, I read in several books that it was important to understand that implementing SAP is very different to many other products. To begin with, I probably didn't really see why that should be the case, but having spent a while working with it now, I can see that point that these people were trying to make. It's necessary to learn how to do it the "SAP way" and almost forget how things used to be done (yes, there may be exceptions).

I'd made that point on my previous visits to the site, but I don't think that they really understood what I was trying to tell them. As a result, they are still thinking on how the process was done in the legacy sysem, and then try to remember how that process is then done with SAP. I know that it is still early days, but I don't think that there is a single person yet that can actually complete a single process on their own, even if they are using the training material that they have.

I did speak to the project lead about this, but he doesn't seem to be too worried. His view is that they will pick up speed and they will all be ready by the time of their go-live. I'm not so sure - I don't think that they have had sufficient hands on experience with the consultants, and I'm convinced that whilst they may have seen a given process, they don't fully know any of them.

Unfortunately, our project lead has been working with SAP now every day for several years, and I get the feeling that he expects everyone else to know as much about it as he does. Even tho he has watched them and seen just how slow and uncertain they are, he is convinced that they will improve in a very short time. For me, I am a bit concerned that they won't keep up their practisng if we are not staying on top of them.

And that of course is going to be a big thing. We will of course provide some support for them, but it's going to be a bit difficult - certainly not as easy as when you are on a single site, or even a few hundred miles apart as long as you speak the same language. It will be much better for everyone if they are more confident in using the system before they go live.

I've also been told that it is absolutely essential they go live no later than the last week of July. It won't be possible for them to continue working with their legacy system after then. I did think about suggesting perhaps we should consider a backup plan in case we can't get the data load, and testing finshed by then, but it was pretty clear that this would not have a been a welcome suggestion.

I get the feeling that our project team are going to be earning a lot of frequent flyer miles!

...And yet another.

When we first started creating the roles for users, I took the advice of the consultants - but after a short while, realised that it was going to get a bit more complicated than I had originally expected. For that reason, I changed the names of the roles, using Z1 for those at our first site, Z2 at the second, Z3 at the third.

The reason for this was that we actually needed to define some limits to what people on each site would be able to do. We didn't want the staff at our second site to have the oppotunity to make changes to items from the main site. This seemed to work quite well, but then I found that some roles were getting very big - and at that point, I started to split the roles down.

We had a hierarchy - sales clerk, sales manager and added a couple of other items to this to allow some staff more access to do certain functions. So for example, 2 staff are involved in contract review, so we have a role for that. 2 other staff are involved in dealing with certain groups of customers, and that is a seperate role as well.

There were some issues right from the beginning, as the project team didn't really understand the concept of permissions - I would regularly be asked to give someone access to something, and when I pointed out that it was to the role that permission was granted, they would get very frustrated. However, it appears that for the most part, they now do understand and we do have a set of roles that serve our needs.

When we started on our first overseas site, I copied the basic roles from our second site, changed the organisational levels and applied user accounts to get them started as Z4. I felt that as we had most of the authorisations already confirmed, this would be pretty much what was needed. I sent details through to the relevant people, including the consultants that I had been told would be doing the necessary work, and waited for some minor changes.

Up until the first day of the work to go thru the processes with the staff, I had heard nothing. Later in the day, I received an email from a completely new consultant asking me to give permission for the staff member to have access to certain t-codes. When I checked, about 80% of those were already in the relevant role, and the member of staff had been added to the role. The few remaining were t-codes that we didn't actually use - we used different ones to do the same job.

I had several more emails requesting access, each time on the day of the process testing rather that before hand. In several cases, I pointed out that the t-codes being requested were restricted to certain people. It was decided that currency rates, period closure etc would be done centrally, rather than have different people at each site getting involved. However, I was also asked to provide access to certain t-codes that I was very reluctant to hand over - why would the staff members need access to things such as SCC4, STMS, SE16N just to name a couple. These are only for administrative positions, and I could see lots of issues if they had access to these.

What I didn't know was that the staff at our overseas site had made a complaint that they didn't feel that they were getting the relevant training they needed and this was passed to our CEO. He then discussed this with the director of the SI, who basically said that I was holding up the work by not providing the required access.

I was dragged into the CEO's office, and to be brief, he told me that the SI were insisting that I give all of the staff at our overseas site the profile SAP_ALL. I tried to point out that this was not good practice etc. but this cut no ice. I highlighted that we needed to get the roles right, but he had been told that this could be done afterwards - in order to get the site up and running as soon as possible, they needed SAP_ALL.

At that point, I told him that if he wanted this, I required him to put it in writing - and I thought that he was going to explode. I won't go into the discussion because it's not necessary, but it was very unpleasant. However, I did get the instruction in writing as I requested.

Someone has subsequently said that he thinks that's a good thing - that when things go wrong, I can produce the written instruction, and throw it back at him. That's not why I did this - when it goes wrong, I will not bother arguing, I'll just get on and try to resolve the problem. My reason for asking for the instruction to be in writing, was to make sure that he understood just how seriously I take the issue.

As it happens, the process testing over at the other site is way behind. They still have almost all of the work to go thru still, and based upon the last project plan, we are about a month behind. There is going to be a big push in a couple of weeks and I have done some work to allow some of our people to do some testing for them. However, I'm not convinced that this will be of any value, as it it appears the consultants are teaching the staff over there different processes to what our people worked on.

I have reason to believe that the SI are pushing to get our overseas site operational on the agreed date, no matter if they are ready or not. I think that this is potentially a serious error of judgement - if they are not ready, we should admit that, and hold off until they are ready. Pushing for them to go live without them being ready could be disastrous - and not just for them, but for the company as a whole.

...and another?

As anyone that works with SAP will know, it is normally set-up as a 3 system landscape. So you have one system which is for development work, one system for testing purposes and another system which is the actual production server - the one that is used by the organization for the day to day work.

The reason behind this is really quite sensible - when you have an ERP system, it is usually really quite important that the production system continues to operate without interruption. Making changes can have pretty serious consequences - you don't want to make a change and then find that it causes the system to fall over everytime someone enters a piece of data (and most people have had experience of exactly that happening).

So having the 3 systems allows you to do development work on one system which won't generally affect anyone else, plus you can then test out the changes on the second system to make sure that there are no undesirable side affects. Once this is fully tested, the changes can be applied to the production system and this will reduce the likelihood of the changes creating an issue that will stop the main system from running as it should.

When we started out, the consultants did actually explain this - however, our project team members didn't really latch onto the concept. Even some considerable time later, they still didn't really fully grasp the purpose of the 3 system landscape. In fact, I would suggest that most of them thought the idea was we would start with the development system, then at some point we would move to the test system, but that that meant the development system was then no longer needed. The same would then happen to move to the production system, at which point the test system would become redundant. They just couldn't see why the others were needed once we had moved to the production system.

Unfortunately, we have had a problem with this - the consultants from the SI and our project leader regularly perform development work in the production system. In some cases, it is just a variant to a report - but on a number of occasions, it has been a bit more than that. There are many times that I've seen our project leader working on producing a new report or even a Z t-code. I can't tell you how many times I have had an email asking me to add a new t-code to a role, only to find that it doesn't exist in the master system.

Now I have raised this issue (more than a few times), but the problem is that every time, he will simply say that he is just following the same procedure as the people from the SI. I can't dispute that - it's exactly what they do. The fact that they shouldn't doesn't come into the argument. It's difficult to say that he shouldn't do it, when the people that we are paying a great deal of money to, ignore some of the most basic practices. And of course, if the project leader (who is a senior manager) doesn't follow the correct procedure, then it's a bit difficult to get other people to do it the way that it should be done. "Monkey see, monkey do".

What I have found a bit irritating is that the project leader does actually understand the reason behind this, and he fully supports my attempts to get people to use the appropriate system. (However, that doesn't apply to him of course!) There was an incident about 2 months ago, and he was bouncing off the walls about the fact that someone was doing what they shouldn't - but he ignored the fact that he had been doing the same thing just a couple of days before. He just couldn't see that people will do as he does, rather than as he says they should.

I remember reading something a few years ago - it's essential to train people up in the way that you want them to work, right from the beginning. There is no point in training people to do things one way, then try to get them to change later as it seldom works out the way that you want. I have to say, we have proven the value of that - I doubt very much that we will ever be able to get people to change their way of working now. I suspect that even if we have a major disaster, they will still carry on in exactly the same way after it has all been sorted out.

But it doesn't mean that it's right - or that we should tolerate it. This slackness leads on to other problems - but more of that another time.

(I've just noticed that there was an issue with the paragraphs on the original post - I've now corrected that. Sorry to anyone that was frightened off by a mass of text!)

Please sir, may I have another?

I've been off work for just over a week - I've not been as ill as that for some time. However, I started feeling better at the weekend, and went back into work Monday.

I went thru various things with my staff, made sure that there were no major issues that needed immediate work, the usual sort of stuff. A bit later in the day, I went in to talk to our SAP project leader and catch up on any developments.

We have a new timetable in place for our overseas site project and the go-live date has already been moved several times. Despite that, they are still behind schedule, and falling behind further every week. He was getting concerned so decided to go there last week and he spent a few days on site.

Now as I have said previously, we have had a number of changes of consultant over there. I'm told that the SI didn't have the personnel available to do the work, so they bought in a couple of people who don't work for them. As far as I can tell, these people were quite experienced (8-10 years) with a number of implementations to their credit. However, these people are now gone and have been replaced by two people that do work for the SI. The first guy has about 2 months experience and this is his first implementation. The second is a young lady with slightly more experience - she has just under 6 months with SAP and this will be her second project.

Our project leader went over to the first guy and saw he had a copy of the blueprint document open, and was in the middle of makings some config changes. He was a bit surprised as he had been told that these were all done. However, when he looked a bit harder at the document, it was version 4 - and the final version which was supposed to be the one we are working with is version 7.

Essentially, a bunch of config changes were made ages ago, then changed to update them to meet the required blueprint. The consultant was in the process of changing them all back to the earlier version (which had already been changed before). Our project leader naturally asked him if there had been any conversation on handing over the project from the previous consultant and was met with a blank look. You can bet he made it very clear that the guy was going to have to get it changed back again real quick!

So feeling a bit frustrated he went over to one of the site staff to ask a few questions. To his horror, the guy was in IMG and was busy making config changes of his own. His immediate reaction was to call me on the cell phone to give me a chewing out for letting the guy have access to this - then he thought he would check to see how the guy was logged on. To his astonishment, the staff member was logged on using one of the consultants logon and password. When he queried how this happened, the guy just showed him a sticky note with the details hand written on it.

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

I am sure that some of you are equally astounded - you may even be shouting. When the project leader told me this, I just closed my eyes and thought of my wife and I on a nice, warm, sunny beach, with a couple of cool long drinks. Hmmmm!

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

For what it's worth, the member of staff has had 2 (count them) days of training. The consultant concerned has obviously been on some SAP course, and she is using the same training material to do the training of staff on our site. When asked if it was appropriate for staff to know some of these items, she just shrugged - she clearly thought that this was how it was done.

So rather than train our people in what they have to do to do their jobs, she has tried to show them stuff that they will never actually get involved in. The things that they will need to know, she doesn't appear to have covered at all. This has caused some confusion and I now understand why I got a rather frantic email from the finance guy on the site demanding access to the entire SAP accounts menu. (About 4,000 transactions?)

Anyways, the project leader is back, he is not happy, and he wants to have a meeting with all of the project team. He is basically going to say that each one of them is going to have to do a trip over there to do some of the site training. I raised this option about a year ago, and the response was considerably less than enthusiastic. Now they will have no choice - and that will cause some bad feeling.

There were other things that I wanted to cover, but they can wait for another time.

Same old, same old

I've been very busy over the last month - there have been a lot of different jobs that needed doing, and I've travelled quite a bit in the process of doing that work. So I've not really had the time to add anything. However, there is something that I am going to post about - and it involves the work that is being done for the first of our overseas sites.

As I've indicated, there is a lot of work that needs to be done for the new site before they can start to use our SAP systems. They have had a group of consultants on site now for some months - I'm not sure how many, as I originally set-up 5 accounts for them, but I know that at least two others have been involved, but as they used the accounts of the others to do the work, I'm not sure who has done what.

Originally, the staff were supposed to have had their training last year, but this never happened. I'm told by one of the staff, that they would see the consultants arrive on site, they would grab a coffee and then vanish into an office, where they stayed until late in the evening. There was no attempt made to talk to staff or managers, and they barely even greeted anyone. As of the middle of January this year, we still had no information on what training would be done when, by who or where it would take place.

Last weekend I was up at our second site - there is some work that has been scheduled for some time, and I spent several days getting it completed, getting back late on Monday night. On Tuesday morning, I walked into a major discussion between people, and spent most of the morning trying to figure out what had happened.

It turns out that a consultant we know nothing about had turned up on the overseas site to do some training the week before. This hadn't been discussed with anyone here as far as I've been able to determine, but it's possible that they had made the arrangement with the local staff, but just not let anyone here know what their plans were.

Anyway, this guy had asked one of the site managers about his user account - I set this (and the others up about 2 years ago, and had sent them all the details. I'd also created specific unique roles for that site, and these had been detailed out in a document that was given to the consultants when they started work last year.

However, the manager couldn't remember the account details - well it's been a couple of years so I can't blame him. I'm told the consultant insists that he tried to call me, but I received no call, no voicemail, no email, nothing. None of my staff were called either. So he went ahead and created a new account for the manager. As he didn't use the format that we have agreed for this, it was pretty easy to see what had been done.

He also created a new role for the manager - again it didn't use the format agreed and it was easy to spot what had been done. Rather than copy an existing role, he created one from blank and then added in a whole menu tree - I haven't counted, but it looks like there are between 3,000 and 4,000 t-codes in there. It also looks like he changed the authorisation objects so that they are set to wildcards for most of the things such as company codes, etc.

OK, so this is a pain, but it's not really that serious right? Except that he had done this directly in the production system. That wouldn't have been such an issue, but he then used that to do the training - and they have created a load of test items in the production system which are just garbage. It caused a real nightmare for the sales people as these items have shown up on their contract review, and no-one knew what the heck it was supposed to be for. Fortunately, it hadn't gone thru to production, or we would have a major problem.

I spent most of Wednesday going thru tidying up the crap that had been left. I don't know what other training is planned, but I'm hoping to speak to the manager concerned tomorrow as he is visiting us. However, it appears that he is on a tight agenda, so I may not get the time I need.

I just feel so darn tired - I think that I need to take a vacation.

Foreign parts

From the very beginning of our ERP selection and implementation project, it was thought that we should choose a product that could be used by all of our sites, including those overseas. The reasons for this are that with one system, we should be able to improve processes, make costs more transparent and improve the communication, analysis and decison making for the whole group. This simply makes so much sense, that it would be difficult to justify any other course of action.

At the time, every single site was using a different system, with different processes, and it was not easy to tie all the data together, as much of it was in different formats. Once the decision had been made to go with SAP, it was made very clear that the sites in the home country would be done first, then the product would be rolled out across the rest of the sites in other countries.

The project was kicked off back in 2007 and the go live was planned for the second half of 2008. It was suggested by the System Integrator that we would then be able to get the first site overseas done in the first quarter of 2009, then another about 6-8 months later, and the sites in other countries at approx the same interval. However, due to a number of other outside concerns, a decision was made that the third site was put back to just over a year after the second site, and then the others were to follow on again at 6 month intervals.

As you'll be aware if you've followed my previous posts, the initial go-live was put back, first by a month, then again and again until a date 14 months after the original planned date. Of course, as we hadn't gone live, it was impossible for the second site to do so. Their date was also delayed and a tentative date of second quarter 2010 was agreed. But as so much work was being done on the main project, none was being done for them. It later turned out that of the little work that had been done, none was really of any use, so in the end, they had to start from scratch.

There was a meeting just under a year ago between the director of the SI firm, our CEO, our project lead and the VP from the site for that country. I wasn't involved and didn't get very much information about what was agreed - I do know that the director from the consultancy sent an email with his take on what was agreed, and it was just 4 bullet points! I was told that he would supply a project plan for the implementation at that site, and that they would be going live on a date just after the middle of the year.

I made myself a little unpopular at that point - I pointed out that the date that he had indicated was actually during a period when the majority of the staff at that site would be away. They have a number of national holidays and various events, and to set a date for a go-live then would have been pretty darn silly. As it happens, once the VP concerned got his copy of the email, he made exactly the same comments. It appeared he had made that very point during the meeting, but it seems that this had been ignored. It took a while but a new project plan was eventually drawn up, this time with a more sensible date, and this was distributed.

So the new plan was that this second phase would see the site go-live at the end of October 2010. I had a few reservations about that, as I knew that there was a lot of work to be done, and altho the site is smaller, and there would have been slightly less work, as they have fewer staff to spare to do the tasks, it seemed that the plans were optimistic at best. This was not made any easier by our internal project team. Most of them were not that willing to spend as much time working on the project for another site as they were for their own site.

I spent a few days at different stages over there, and I tried to keep in contact with their people. It became obvious that they were falling behind very badly almost from the get go. I tried to see what I could do to help, but it just seemed that as we had experienced with the project for the main site, nothing seemed to stay on schedule. There was little communication, and we had to try to get information for ourselves on the progress.

There was a meeting organised last September - the director for the SI apparently made a statement that we were on schedule and the site would be ready to go live on the date agreed in October. When I heard this, I couldn't believe it - I went into the CEO and told him quite bluntly that this was garbage and showed just how little work had been done. There were some very tense audio conference meetings at which I was accused of being an "Organizational Terrorist" by the consultants. (I'm not quite sure what they meant by it, but it was obviously not intended to be complimentary.)

As it happens, it became abundantly clear that the second site is not ready (and they still aren't). The consultants working on that site were still making config changes right thru to Christmas, and none of these have yet been transported. No data has been extracted from their old systems, so of course it hasn't been loaded. None of their staff have yet had a single training sesson - and as a result not one piece of testing has been carried out. The consultants were complaining that the language packs had not been applied as there were several errors. We have since identified that in fact all of these are in place and working - the missing text is all stuff that they would have to add manually.

At this stage, I don't think that we have a date for the go-live at the second site. Someone did suggest May this year, but I can't see that happening due to the amount still to be done. We are then almost into their main summer holiday period, plus the national holidays again, so I have a feeling that we could in fact be looking at September or October of this year before they will be ready. In other words, they will be going live about a year after the date set for them as part of the revised project.

Now I have been trying to understand why these dates are so clearly out of sync with the project plan, and I feel that I have something to add. I'm sure that what is happening is that the consultancy are using a generic plan that says, X many days for step 1, Y many days for step 2 and so on. This is fine if the allocated amount makes sense and also if they then actually communicate that information so everyone knows what is required.

I am going to say that I don't believe that any meaningful communication is taking place. The reason that I say this is the consultants doing the work didn't seem to know about the stages and had no idea of when anything was supposed to be completed by. But for me the biggest issue is that it appears the director of the consultants is not even checking to see if the work has been done. His plan says that stage 4 should be complete on day 71, this is day 72 so stage 4 is now complete. If it isn't, he just ignores it and carries on to stage 5.

I'm sure that for some people, this makes sense - but I really cannot see it. If the work is not complete, it is not complete. I accept that if you have a fixed date on a project, sometimes you have to make a decision to trim the workload to make sure that you achieve that fixed date. But in this case, trimming the workload is not an option as that means the product won't work - and it then makes sense to make sure the work is complete even if the date has to slip.

So I suspect that I'm going to be doing some travelling later this year - going to have to dig out my old language tapes to brush up!