You work with Microsoft Dynamics. Either as an end-user or partner. And although Dynamics is much easier than other systems, then things go wrong here too. But are all your Dynamics projects (both big and small) always on target, on time and on budget? The question is not, if the reason is at the partner or at the end-user.
Hmm, not sure if I should vote here, since my job is fixing failed NAV projects, logically all the projects I work on fit the failed category otherwise I would not be there.
I really don’t know why but invariably the budget is too small, but it happens alot where the project budget is put to the test quite seliberately. It almost seems like Solution centers deliberately manage their projects to go over budget. So many times I have seen budgets blown on hours or dollars, and despite early warnings projects have been managed toward failure. Time after time priorities have been set in such a way that the timeline was in danger, where time sensitive pieces were given lower priorities, or high risk pieces were not given high enough priorities. As extermal freelancers it is really difficult to stay in your role as contracted development resource, when you see customers not being warned about obvious project risks.
In that case I would say that all of your projects had one of the three problems! [:)]
Hi Daniel,
You say that the partners do this deliberately?? And how are the customers reaction, when they find this out?
I have been on projects that were sold with the client agreeing to no modifications to meet the set budget, then in the initial workshops they require barcode scanning, and 25 other business critical modifications and 30 business critical reports. Originally the client was going to write the reports themselves, but no longer have the resource or time. Originally there was no data migration, and now there are 10 scripts required…etc etc
At times the intial budget is massively crashed due to the customer changing the goalposts - now the solution centre will know the client is likely to do this, and will tell them, but at the time of the sale the client knows they will not do this, but early in the implementation they realise the truth and the budget goes out of the window.
However I also knwo we lost NAV sales to other resellers who massively undercut us and you wonder how the hell the system would be implemented with the developement we could see from the start, but in many cases the client looks at the bottom line, not the partner or the project.
The customer has a diffiuclt reaction to make when they find out that the projects are over budget, because they are generally the cause - however it depends whether they were aware of this or hoodwinked into thinking it would never happen!
Well maybe I shouldn’t say that projects are deliberately steered toward failure, that is overcharging it quite a bit. I do think though that pretty major mistakes are made again and again, and it always amazes me how there doesn’t seem to be a learning experience, where the partner goes “hey we did that in our last project and it failed, let’s do that differently this time”.
What I am talking about are things like pushing high risk development toward the end of the project, and do the easy ones first, to make it look like a lot of progress is being made, or putting the less experienced developers on the most difficult customizations. Another one is where the customer is indulged with making NAV behave like their legacy system, instead of really digging into the functional requirement and coming up with a solution that works better in NAV. Another one is where the customer is supposed to do the data migration and reporting, and the partner doesn’t start pressing until it is really too late in the game.
What goes out the door I would say 90% of the time is sticking to a methodology, and following up with proper documentation. A lot of times “we have x methodology” is more a sales gimmick than a true statement. Ask the PM for instance for a project charter, a list of functional requirements, prioritized by business need, with high/low budget numbers, high/low risk assessment, project plan, design documents, change orders, technical documentation, test plans, issue tracking, the list goes on and on. When was the last time you were in a project that all of this was meticulously kept up to date?
I really don’t think that partners deliberately let projects fail, that would be a very unfair thing to say. Let’s just say though that it is more profitable for a project go over budget than to come in under budget, and leave it at that [:D].
They always get done but sometimes outside help is required. Usually always over budget/time.
- perhaps those failed projects come from those 7,1% answering “I don’t know” [:^)]
What goes out the door I would say 90% of the time is sticking to a methodology, and following up with proper documentation. A lot of times “we have x methodology” is more a sales gimmick than a true statement. Ask the PM for instance for a project charter, a list of functional requirements, prioritized by business need, with high/low budget numbers, high/low risk assessment, project plan, design documents, change orders, technical documentation, test plans, issue tracking, the list goes on and on. When was the last time you were in a project that all of this was meticulously kept up to date?
I agree to this 100% but there is a pain area here as well , if u working as consultant and have been asked to do PM actvities as well on for not 1 but 4-5 projects going simultaneously then it is bound to happen. And i am saying this because i have first hand experience of this. I don’t know whether it is employers money saving tactics or what but it does not help anybody not even people working on the projects.
One of the primary reasons i see for faling a project is, u r just asked to make the budget on mpp but finally the budget after negotiation is given by Sales that solves the mistery “why it failed” many times. Oh i think u shud revise WBS because client said not more than Xk dollars so pls revise it the way u want but keep all promises of landing them on moon intact. That really su…
So failure, if happens, is a team game but in failing situation onus is 90% on the partner then the client.
I answered “I don’t know” because it depends on how you define “success”, “budget” and “on time”. There usually is the budget and timeline that was in the original contract and restricted the project to certain deliverables. Then there is the budget and timeline that were revised after realizing that the restrictions in the original plan were unrealistic. I’ve worked in ERP for the past 14 years. If you exclude those cases where the project was botched by inexperienced consultants or weak project management (internal or external) then the problem was mostly: the original estimate was not realistic. There is an inherent problem in every complex implementation project: to come up with an exact estimate you would need to know the exact requirements. That is impossible in the pre-sales phase even with best efforts on all sides. Consulting companies are limited in how much unpaid time they can afford to spend before the customer signs. Customers on the other hand often falsely assume that everything they do is “standard functionality”. Oftentimes things look pretty standard to everyone until you dig into the details. Software vendors and consultants assume that their clients can change their business processes to whatever is “best practice” with “best practice” being whatever their system functionality is. Almost every company is different though and you’ll find processes that don’t fit into a “standard” system but have been optimized over time for a business and should be kept. Neither customer nor pre-sales consultants can afford to analyze every detail before the project starts (that’s half of the project).
An experienced project planner will add buffer time to the estimate for those “unknowns” based on his experience. In consulting companies there is a lot of pressure on the sales guys and the “pre-sales consultants” to make the sale. Being too realistic in the pre-sales phase can get a consultant kicked off the sales team and justifying buffer time is difficult if the competition estimates a lot less. As a result the buffer time is usually what gets scratched out of the SOW and instead a lot of fine print gets added in to make sure that these things are excluded from the contract. The customer assumes that the consulting company understood their situation and wouldn’t sell them something that doesn’t work. The consulting company assumes that the customer understands the limitations of what they sign. As a project manager on the delivery side you then find yourself in the uncomfortable position of constantly having to tell your client that things are “out of scope”. So, yes technically as a consultant you fulfill your contractual deliverables and stay within the budget that was agreed upon in the SOW - but it doesn’t feel like a success. To add the “extras” that turned out to be essential your customer had to go over what they had budgeted. Companies underestimated the time their own employees will need to invest in the project because they weren’t aware of the full complexity. The initial time line gets extended. Regardless of who is to blame: nobody is really happy.
I have to say though that over the past 10 years I noticed that the customers I’m working with have become a lot better educated. My experience is that many customers these days do understand the possible pitfalls and are a lot more critical of overly optimistic estimates. Most of my contacts on the customer side now have at least one ERP implementation under their belt and many are even former consultants. As a result I’m also seeing customers taking over a lot more responsibility for managing their projects and I’m seeing less failed projects than before.
I found this page about success rates of ERP/IT projects in general:
http://www.it-cortex.com/Stat_Failure_Rate.htm
That’s very sad reading!