Keeping Projects on Track
Just last week, a colleague asked me to run down a few of my experiences about projects that go awry. Here are a handful that we have observed:
1. Inconsistent team participation - This is especially true of longer term projects. One of the worst things that can happen is to have team members turn over. So much of a project is about context and getting people to share a common understanding of the problem and solution. When team members (whether internal people or external resources) turn over, it is very difficult to achieve a consistent understanding of that context and the direction of the project.
2. Organizational fatigue- How many times are you going to interview people and ask "tell me what you do for ABC Corporation"? People get sick of it - especially people in the senior ranks of the enterprise. They don't have time to tell people over and over about what needs to happen, what the problems are and what their role in the organization is. In order to revisit these issues, you need to show some progress or change and take a slightly different perspective on the nature of your investigation. And of course, coupled with item number 1, where the original people had to move on, this is a very bad situation - it demonstrates that you are ready to waste people's time and ask them the same questions as the last consultant.
3. Insufficient executive buy in, support, commitment, etc - this is one that comes up in multiple contexts and in many manifestations. It can appear that yes, there is an executive sponsor and yes, she is attending status meetings. But is she really connected to the project? Or is her "delegate" showing up to most of the meetings. Decisions cannot be made by proxy. There is just not the same level of skin in the game. Attending a weekly conference call is not the same as being truly engaged. Delegating decision making is not the same as making a decision. Direct reports to the senior sponsor have to see that it is important enough for the leader to attend working sessions and ask questions and debate options. Otherwise the message is "this is not important enough to warrant full attention".
4. Glossing over conflict for the sake of "moving ahead" - I have seen important dialog stopped dead in its tracks when a session facilitator has declared "these are good points, but we have a lot of material to get through" and go back to the slide deck, squelching true engagement. Getting people to buy in is not the same as having them attend a meeting, sit through a slide deck and nod their heads. They will only leave the session and say "that'll never work". A good session leader will look for body language - subtle frowns, crossed arms, silence, rolled eyes, that look that people have when they have an issue or take exception to a point - and use that to encourage disagreement. That's right encourage disagreement. How else will you resolve issues that people have? Not by keeping them quiet. If that happens, they will sabotage the project through passive aggressive behaviors or through other not so passive behaviors. (Like telling their colleagues and subordinates why the project won't work)
5. Depending on technology to solve people or process issues - How many times do we have to talk about this one? But it still happens - over and over again. Why? Don't ______ (choose your scapegoat- managers, it people, users, executives, analysts, architects) understand that its not about the technology, blah, blah, blah, blah, blah..? Because it’s not that easy. Of course people know this. But its when we think that the people and process issues are understood that we choose a technology and try to implement it. But this, like any project or process, is an iterative approach. The challenge for a project manager who is measured on time and budget issues or for a consulting firm that will need to meet deadlines is that stepping back when a new issue is uncovered is not conducive to bringing projects in on time and budget. They are measured and rewarded for plowing ahead and making things happen - even if those are the wrong things. It is a delicate balancing act and one that requires judgment and experience to mitigate. When is it the fault of organizational processes and when is it the fault of informal work practices? When is it technology versus process? And so on.
6. Moving targets - "Nothing endures but change" (from the 5th century BC). How far out do we try to go when we are trying to determine requirements? Today? Six months out? 1 year? How well can we predict these? When we're building systems and processes and doing user requirements, its easy to either behind the curve (users need more than we anticipated and their needs have changed by the time we deploy the solution) or ahead (by developing capabilities that they are not yet ready for). Getting this right is a tough balance.