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.