Who’s complaining?
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.
Dotted line agreements
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.
It’s when issues come up
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.
