Projects are Too Big
A big challenge in requirements are today is that projects are often too big.
So my immediate reaction when talking about this with coworkers was to form an image in my head of a little guy (think Ziggy) standing in front of a 3 story wall that’s about 60 feet long. On the wall is a representation of the entire project; it’s covered in diagrams and scratches of text…very “engineering like”. Little Ziggy is looking up at this wall and is completely overwhelmed with where to start.
But in all seriousness, I have seen it time and time again, huge projects with many system integrations and literally hundreds of people involved. Executives want to change the world, and teams of developers, business analysts, testers, business users, etc. set out to do just that. And frankly, none of them seem to deploy on time or budget. I think they believe they can subdivide the project into parts, and have smaller teams own the parts. Unfortunately, this is almost never well managed.
In fact, in another post, I talked about the differences between systems and software projects and that one of the needs was to have someone accountable at the system-level for communications. But I question whether realistically one person can own such a large project and in such a way they can actually understand all of the moving parts.
At the end of the day, the only way you could manage a project is to have the right tools. And it’s not just tools to manage requirements, but tools to manage communications also. A team of 100 people can’t all possibly know what’s going on in all other parts of the project, and so that gets pretty risky. They need to be able to understand dependencies, and flipping through word docs won’t help that. Sorting through massive email threads won’t either. Getting 100 people in one room isn’t realistic. So, the best we’ve come up with so far is some tools to create an environment in which large teams can communicate, review history of communications and filter on what they care about.
posted by Joy at 12/13/2007 10:00:00 AM
3 Comments:
Economic indifference was designed to handle this situation. It isn't necessary to know all the details. It is necessary to communicate clearly to those that know all the details. It is necessary to deal with the dependencies and interfaces between those who know. It is necessary to enable, rather than disable, motivate, rather than harass, inspire, rather than zap.
There is no room even in a small company for the all knowing.
If the PMs and operations managers don't get out of my hair, the only project that gets completed is my moving my stuff to another desk at another employer.
Coupling and cohesion work to separate concerns in large bodies of code. Programmers have their reasons to modularize. Projects have their reasons to roll up.
If you look at the large project, putting the requirements together is about learning. Same for the act of putting the project plan together. Same for refactoring. A project is a learning exercise.
I once worked with a VP of Research who refused to have a team with more than seven members. That was his cognative limit. You might think of a project the same way. Instead of clock time, think in terms of concepts. Put them on a cognative axis.
Since a lot of the large project will involve the same things done in other projects, aka reuse, the learning represented by that effort is implicit and baseline. Only the customizations would involve new learning. Code that isn't touched has no learning involved.
Risk and learning are linked. Managing a project is managing the risk and the learning.
Yes, it is hard to be dropped into an ongoing effort that is already large. The decisions made in the past are probably lost.
Thanks for the comments, I've added them to the message board for further discussion:
http://www.seilevel.com/messageboard/showthread.php?p=3754&posted=1#post3754
Post a Comment
<< Home