Home

What’s worse: too much or too little implementation time?

When we tend to prolong an implementation, it becomes a problem. But when you stretch it too thin, that's a worry too. When we rush this, I have seen IT has no time to get the right vision from stakeholders. We then lack user stories, a good amount of User Acceptance Testing (UAT), and think about change management and enablement, which is the key to successful implementation because there's only that much time.  So even if we claim victory in a record implementation time, we're left wondering, was the project successful? I believe the magic number or formula is somewhere in between.

Anonymous Author
When we tend to prolong an implementation, it becomes a problem. But when you stretch it too thin, that's a worry too. When we rush this, I have seen IT has no time to get the right vision from stakeholders. We then lack user stories, a good amount of User Acceptance Testing (UAT), and think about change management and enablement, which is the key to successful implementation because there's only that much time.  So even if we claim victory in a record implementation time, we're left wondering, was the project successful? I believe the magic number or formula is somewhere in between.
3 upvotes
Anonymous Author
A lot of the enterprises need to follow the startup world’s lead and just implement things without arguing about changing and customizing them first. Because 90% of the functionality will work and they can adapt to using it, rather than trying to customize it to mimic the exact way they want to do things. I've come to the conclusion that sometimes you're better off saying, "Forget your current processes. We're going to put this in. Start using it and maybe we'll go back if there's a real problem." The normal enterprise approach is to spend the first 3 months arguing over the processes and how you want to change the software to fit your processes.
1 upvotes
Anonymous Author
Both are not ideal… if you have to choose one then too much time is better then too little time. You can have the time but pretend you have just enough so you finish/implement the project and them use the slack time for something else, otherwise things can get dragged and you loose focus of the objectives.
0 upvotes