Excellent remarks, Bernie. I love the idea of treating a change request as a ‘defect’ in the “planning stage”. I don;t want to say requirements or design because that may lead people to think of a specific document. In my mind, the change request was necessary because somewhere the process itself didn’t work, and now we have an exception to be dealt with. The question to my peers would be, How do you propose we prevent this from happening?

It’s easy to tell people to plan at an appropriate level of detail, as we do here on this blog. But finding that appropriate level for plans that are 1 week, 1 month, or 1 year out (with less detail for farther-out plans) is definitely subjective and can be contentious. As we both know, large organizations have a strong tendency to overspecify and overplan. They understate the unknowns, risks, and future changes that will be necessary in those plans.

It sounds like you’re doing a bunch of right things by introducing short-cycle, priority-based project management (Version One) and by setting an example with your architecture/dependency/status diagram — you’re keeping it on a single piece of paper, so the details can evolve appropriately.

One other idea is to introduce a feedback loop. When change requests are generated, they can be called a defect in the plan/specification — but perhaps the defect was, in fact, specifying a detail that shouldn’t have reasonably been known at the time. In other words, the defect was overspecification, and that level of details should be left to later in the project, when more information is available. Likewise, if CRs and bugs are flagging things that had no risks or unknowns, then there was underspecification.

Culturally, you have the challenge of convincing your architects that they must create designs that can change and evolve and respond to learning. It one sense, that makes their job easier at first. But it makes keeping the coherency of the design over the project much more difficult.

I always like pointing at the open source community, for better or worse, as one that deals with extreme change over time. Some would say open source only copies designs — but I think, looking closer, that many open source projects forge lots of new ground, and do so with designs that tend to start simple and evolve to a more complex, holistic design over time.

It is possible to iterate towards as optimal design. In a domain with lots of unknowns, in fact, it’s probably the only way to approach an optimal design.

Kidding. We have skilled architects, however, we find ourselves in a loop. The architects tend to want to know the details on the five year plan so they prevent poor decisions. The business, well, they can’t make up there mind for what they want two weeks from now. Typical Software stuff.

The thing I like about what is advocated here is to focus on the work flow, maximize the efficiency. Obviously, you can complete the work in queue unless these decisions have been made, but I’m assuming by waiting until the queues clear, you have better information for the architects to make the right decisions.

Unfortunately, we still plan everything out in great detail nine months in advance and then act surprised when we have 100s of Change requests. All waste.

At the level of scale you are working with, I’d say the most important thing is to align the structure of the organization with the architecture (and not vice versa!). I hope you have some first-rate architects on board.

Would like to hear more of the detail.

I'm not at home right now and I'm using a computer that isn't mine so this post contains…

A strict waterfall approach with containment dates is being enforced. We are challenged to coordinate all activities across all teams effectively. Our PMO has implemented complicated reporting structures. This reporting structure is a huge burden to our resources and ultimately takes away from our productivity, as wells as the lack of communication across teams.

There are some things I have done in this environment to change the way we track our progress and communicate. I am trying to present the environment in lightweight models of business functionality and technical components. I’m using what I would consider a functional diagram, rather than a use case diagram. In this model, I call out the various interfaces. We have interface within teams, across teams, and external to the organization. I am accountable for testing and quality and I color the map according to testing progress. Each component is tied back to a test suite (manual testing). ON a single piece of paper a team member can quickly determine the overall health of the system and can estimate the work left to be done.

For project planning, I’m a big Version One fan. We’re still struggling with acceptance, but I’m certain that the tool allows us to focus on a more Feature driven development approach. Hopefully that will mature.

Love to share more.