Who Can Say No?
February 3rd, 2009 Jim Kiley, Consultant
In order for an IT project to succeed it’s necessary to have support from all of the stakeholders. But it needs more than that.
In most medium and large IT shops there are more people who can say “no” to a project than can say “yes” to it. From an IT governance perspective, it’s important to ensure that the only people who can obstruct a project are people who are authorized to do so. This requirement might best be described with…
A Made-Up War Story!
Arnold, Betty, and Chris have seen a need to modernize an aging, hard-to-maintain desktop / command-line application by converting it into a web application. This application pulls data from two databases that already exist. The application is small and the team has an eight-week timetable. The project has been approved by the IT Project Board and has enough budget for a team of three for eight weeks.
Arnold’s manager Dave — who doesn’t have a big investment in the project’s success — tells Arnold during the project’s first week that Arnold will need to spend 50% of his time for the next two weeks getting knowledge transfer from a developer who is leaving the company. Regardless, the team plunges onward.
Eve, a DBA, has been provided to the team on an as-needed basis. Eve is juggling a few projects of her own. She misses half of the project meetings that she’s invited to.
Frank is responsible for the company’s production server farm. He prefers to work with technology he understands well — and he knows Solaris, Java, and Apache technologies well. Unfortunately, Project ABC is a Microsoft .NET project. Frank needs extra time to get up to speed on Project ABC’s technology, and he takes a few minutes out of every project meeting to complain about the team’s technology choices.
Ramifications
Joanna Lethem’s Manage It! suggests that a project with more than three major constraints will probably fail — and that’s when the constraints are well-defined and understood by the project team. Nay-sayers and passive obstacles like Dave, Eve, and Frank represent unexpected or unseen project constraints, and can spell a project’s failure even though none of them has the authority to cancel a project.
These sorts of dysfunctions in an organization can greatly increase project costs, blow schedules, and reduce the likelihood of project success.
Who Can Say No?
Let’s look at people who can say “no,” either actively or passively.
Team Members’ Managers – In many corporate environments, project team members report to different managers; not all of those managers are directly involved with your project. Team members’ managers’ priorities may not sync with project goals.
IS / Infrastructure – In addition to juggling infrastructure requirements from multiple projects, corporate IS groups have to pay closer attention to so-called “non-functional requirements” — availability, security, and responsiveness — than any given project team does.
Peripherally Involved Developers – Developers who are responsible for maintaining libraries or dependent technology may inadvertently impact a project’s activities in a number of ways.
Enterprise Architecture – Enterprise architecture teams must ensure that projects fit into the organization’s overall IT strategy. This includes software technology standards, integration interfaces, and so on.
Solutions
Dave, Eve, and Frank exist in every shop. The problems they cause — with the best of intentions — can’t be resolved in a single blog post. But they do point to a key theme:
IT management must align the power to say “no” on a project with the authority to say “no” to that project. That means that at the early stages, at the approval stage, there should be voices on hand from the infrastructure group, from developers’ managers, and any enterprise architecture team. Obviously, some employees can interfere with a project’s success at later stages of the project, but project teams must be able to fall back on the authority of the project board and push their requirements through where needed.
Entry Filed under: Process and Governance
2 Comments Add your own
1. PM Hut | February 3rd, 2009 at 4:04 pm
I have to say that the examples given as “unexpected” and “unseen” constraints are not the greatest. I think all of this could and should’ve been accounted for in the original Project Plan. IMO, this is more of bad Project Management than constraints.
2. jhkiley | February 4th, 2009 at 10:54 am
I agree that nay-saying and passive obstruction aren’t, strictly speaking, constraints on the project. But they frequently do take project managers — especially novice project managers — by surprise.
And from a project governance perspective, I think it’s depressingly common for these sorts of problems to occur but never quite trickle up to the upper tiers of IT management.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed