Make It So… If Only Software Project Management Were That Simple

Sounds silly, doesn’t it? Yet many traditional command-and-control organizations think they can work this way.

Manager types go behind closed doors and through a series of many meetings come forth with “The Plan.”  The plan directs what is to be done, how it is to done, when it is to be done, and by whom it will be done.  The software developers who must implement the plan are informed of the plan and directed to “Make It So.”

Almost immediately it seems a question will be raised with the realization of, “oops, that was not considered…  it is not in the plan.”

But, the Project Manager’s job is to create and then deliver based on “The Plan.”  They will be evaluated based on that ability.  Their performance and success is measured by variances to the plan and they report these variances every month to their superiors.  As is typical with human behavior, it does not take long for a savvy Project Manager to realize that, “hey, if I want to keep my job, or better yet, get a good raise or promotion, I better not have variances.”  Variances to a plan are bad.  So the project management function seeks to control and, thus, essentially prevent change.  Change becomes a threat to success of the plan.

So, you must follow “The Plan” and stay on schedule and on budget – deliver the hours and the planned activity and events. 

But, the Customer wants everything they asked for, so you must deliver all content as well.  No, they cannot add anything that will change the plan. 

If the developers cannot stay on task as defined, they simply must work harder and longer because “The Plan” must be good.  Then they must explain in detail why they could not accomplish what they were told to do within their budgeted hours.  Just Make It So.

Waterfall project management wants fixed schedule, budget, and content.  Actually what they really want is that big raise for demonstrating how great their plan was and how well they controlled the project through the plan.

If this project is actually well understood up front and what’s to be accomplished is pretty stable, then this approach may actually work.  Project managers are smart people too, and they can effectively apply experience and judgment to make good plans under the right conditions.  Some industry is very heavily regulated and only a very precise and specific requirement is acceptable.  This approach can work well and, if it does for you, then great…. Make It So. 

But, what if the software product must evolve to changing conditions and needs?  Today’s rapidly advancing technology means end-users are increasingly fickle about what they want.  Many agile software project management products now are being provided to model business processes and interactions, either for internal or external customers.  These processes are under pressure to constantly change and improve meaning that the supporting software must also change.  Companies cannot maintain a competitive edge unless they change and evolve rapidly.  Software projects must be prepared to do the same.  Does it really make sense to tell your customer they cannot have the thing they discovered they really need now because it was not in your plan you made months ago?

Like science fiction, plans rarely mirror actual reality.  Trying to fix schedule, budget, and content is a real challenge for a number of software projects in organizations today.  In reality, one of these parameters must be allowed to flex.  End-user software is very hard to define up front.  Users often do not know what they want, and even when they think they do, they quickly evolve to need something else.  Plans must be able to adapt and yet still provide the business with the insight that it needs to manage teams effectively.

This “Make It So” approach must evolve and, with it, the behaviors of project management and the measurements of project/plan success.  Even really good project managers cannot control the future.

Maybe it is time to “boldly go” and explore a new “agile software development” approach – one that provides immediate visibility into the health and status of the project real-time, and readily allows for a changing parameter (content, schedule or budget) to be understood immediately. 

What do you think?