The executive impulse to “throw people at a project”, though well-intentioned, can cause more problems and slow things down. Why?
Each one of those people need to be on-boarded into the project.
- Getting them up-to-speed on project objectives, timelines and activities
- Getting them the appropriate system permissions
- Teaching them any new systems and the location of any support resources
- Setting performance expectations and reinforcing those expectations.
If there is significant resource churn – it’s like being in a constant forming / storming loop without ever feeling like you will ever get to norming and performing. (See Bruce Tuckman’s Team Formation Model.)
Each time you add a person, you send the team back to the forming step.
Each time you add a person, you are often pulling a key project resource away from doing the work necessary to make the project successful (such as making sure the new system actually works) to help on-board the new person.
But you still need the people. The bodies to make the project happen on time.
The trick, I think, is to identify those needs earlier and get those people on-boarded sooner in the project.
Getting your trainers (who are really needed at the end of the project) involved around the time you have a live test system. They will also provide important feedback around usability.
Involving anyone who will be doing support and operations at the beginning of the execution stage – which can also serve as risk mitigation if your technical lead or another key technical contributor decides to leave.
Identifying someone as a Business Analyst (BA) for your solution – if your organization doesn’t have one already. There needs to be an organization-side translator between the vendor and the rest of the business. And a back-up. Get the main BA involved as early as possible. Begin training the back-up at execution.
Identifying testing resources during Planning and getting them trained – both on the tool and what to expect in the testing process. They may need frequent reminders that finding errors is GOOD and that the earlier these are found the better.
Identifying any Power Users during Planning and getting them trained on the tool and getting their feedback on how the tool works (or doesn’t) in their environment early enough to make changes.
The sooner a project team can on-board these resources, the sooner they can start norming and performing.
And the more your project team can focus on things like getting your new upgrade running.
There will be some resistance. Particularly if the organization is operations-focused and runs very lean.
“But my person has to do x……”
It’s a bit of a test for the leadership of the organization. How important is the effort, really?
Are they willing to provide the resources for the effort to be successful – both immediately and in the future?