Saturday, March 8, 2014
If the IT team is complaining about the business not doing their share of the work, then the goals are not clear enough and are not tied to direct accountability. Why would you expect someone to go out of their way to help when that person has no “ownership” of the project? How many times has IT bulldozed an initiative through the business successfully without full cooperation and understanding from the business side? So, if individual team members of the IT team are annoyed, it’s time to reconsider the approach to implementing the solution; somewhere along the line a piece of the puzzle is missing, and it will be obvious when you look for it.
Your project is large enough to span systems which integrate. There is a risk in planning a project with teams who have competing objectives. Scheduling the rollout of the project can be tricky. The dotted line between your project’s goals and the associated extended teams can be deceiving. Make sure there is enough oversight by a “steering committee” which will back up the project during the critical milestones and implementation.
Designs and specs can fall apart when seemingly insurmountable problems arise. In large projects, issues always rear their ugly heads. This is when the team’s cohesiveness is tested. Will everyone rally to fix the issue in a timely manner? When a project schedule slips, there’s usually an issue. The root of the issue can be traced back to some assumption, scope creep, personnel change, etc. The root needs to be explained, transparent and fully understood. This is the learning moment and shouldn’t wait for a post mortem. Explaining what went wrong after the fact is lame and not as impactful.