Project management needs to be tweaked, particularly for large and lengthy projects. In project after project that I see, the same problems repeat themselves: - Sponsors, especially money-managing sponsors, get too much weight in the evaluation of what's ultimately implemented
- Actual users of the system, whatever it might be, aren't consulted nearly enough or early enough and aren't given the voice they need to make it successful when they are engaged
- The lengthier the project, the less likely it is to meet the needs of the business because there's no agility - gotta stick to the requirements document, don't you know (which was older then and couldn't know what we know now)
- The project team, cobbled together from available resources, doesn't know each other typically and so many skills are squandered for the definitive roles in which they are cast
All of this leads to projects that over-promise, under-deliver, and ultimately waste money. Project management becomes a game of horseshoes, where close enough is good enough. Instead of maximizing the benefit of every dollar spent on the effort, we're satisfied with some measure of return on the company's investment. Pish posh. Customers and co-workers and stockholders deserve better.Sponsors, the money-managing ones, are necessary. I don't mean to belittle their importance, but they should never dictate what's implemented. They generally don't know the business at the level of implementation. Or if they do, they knew it when they worked at that level, and in most cases, business has changed since then. Their expertise, whatever it might be, should take a back seat to those in the trenches now. What typically happens, though, is that the project plan is presented to the sponsor and then features are questioned and the project team is told, "You don't need that. What's that for?" And because it's the sponsor, it's thrown out. Users grouse. Off to a good start already. Users - those in the trenches - generally aren't pulled in until later. "Gee, I wish I would have spoken with you / known about you earlier," someone on the project team will eventually say. It's not uncommon to have intermediaries between the users and those implementing, and those folks tend to inflate their own expertise. The point is: there is no substitute for direct meetings between the user and the implementer. Less is lost in translation, assumptions are driven out more quickly, and buy-in by the user base generates good will. All we need to do is listen. Where's the harm in that? Budgets and schedules are generally based on the BRD, or the business requirements document. This document is built during the planning phase of the project. But instead of being the scaffolding it needs to be, it becomes the foundation. If changes are made, then they have to go back through the change request process which invites design by committee and sponsor-domination. I completely understand why there's a need for this process. Budgets and schedules matter, but here's where things go awry. Rather than kick it back to the project team and the users to figure out how to rework things to meet budget and schedule, executive decisions are made and the project changes from the top-down, and not the other way around. There's no flexibility to design a solution with the elegance of better knowledge. Good design is, unfortunately, lost. Part of the problem is that the project team is assembled from available parts. While I'm a big fan of the wisdom of crowds and I think that diversity is good for a team, research shows that surgeons who work at multiple hospitals are most effective in those hospitals where they have the most time with a surgical team. There is no truth to surgeon portability. Think about it: when you work with the same team over and over again, your efficiency goes up. Likewise for project teams. You know each other, and you know strengths and weaknesses for everyone. (I don't have a link to source the study, but I'll find that and post it later.) Not all projects require a finely-honed team, but if it's a long-term or complicated project, adding newness of personalities and talents to the project only furthers the complication of the project. Not a great way to do business. (Which I think invites the question: is there really any efficiency gained by assigning people to multiple projects with people they've never met or barely know? Or is it better to have the same team work together, even if this leaves some space for additional allocation?) My prescription: create core teams. Know the strengths of the team and let those in the team know each other well. Let them move together to resolve the problems that projects aim to solve. Involve users from the beginning and have the core team work with the users during the planning phase to arrive at the right design. All budget and scheduling should be okay'ed by financial sponsors, but feature / design / implementation decisions must be made by the core team after dialogue with the users to determine the ramifications of these decisions. Yeah, a kick-off meeting can help alleviate the problem of newness, but c'mon... if I've worked with you closely for the last year, no single kick-off meeting can create that synergy. Spread that across a team and you only multiply the problem. In part, this was prompted by a meeting that I had yesterday with a person who needed to see some web development that I had done. They'd never seen my development or this particular corprorate web site I'd built before. After seeing the work I'd done, they looked at me and said, "I had no idea you could do this." This is relevant because I worked on a project with this person for 4 months last year. Had they and the others on the team known this side of me, some of what I said on the project might have had more weight and might have allowed us to create a solution more quickly. But as it was, I wasn't as useful to the team as I could have been. Some of that is my fault - perhaps I should have pressed harder and demonstrated my chops, if you will. But the team had been together on this project for a while already and I was the new guy, so my opinions had less weight. Each of us has passions and talents that aren't known to those with whom we work. In my opinion, HR should bank every talent and passion we have and make it available in a database. A resume and skills inventory is not enough. I've written about that before. But it's better if we work side-by-side with a core team. Then we know how what we offer meshes with those on the team to produce the greatest results. That will help bring projects to a robust solution and completion. |
