Managers and Project Managers expert in standard project management bodies of knowledge and management theory are absolutely capable of making a shift to flow-based iterative software engineering behaviors. The required organizational cultural shifts, behavioral shifts and daily operational practices will be different from predictable, repeatable manufacturing bodies of knowledge and different from text-book PMI and Prince2. The limiting factor, while expectedly challenged by cultural, political and bureaucratic complexities, will actually be two personal limiting factors:
- The type of experienced manager or project manager who is old enough to believe they've already learned what they need to know for success and therefore already understand something insignificant like software; and/or
- The type of person who is unable to admit inexperience, uses an opaque interpersonal management approach, and believes command and control leadership structures were the only chapter in the management theory books of use.
A person with previous experience, education and developed skills who doesn't know anything about software is capable of learning and evolving. The limiter will always be themselves and their ability to adapt.
Were I to have an enterprise software program in a legacy hard-line manufacturing company that over-spent, under-delivered, underwhelmed or consistently delivered something less than my competitors, the first place I'd look every single time is the leadership. Obviously we'd assess the teams and behaviors, specification behaviors, organizational prioritization and commitment history and practices, marketing and sales impacts to the delivery chain and more. However, Step 1: Leadership. Why?
Leadership defines goals, aligns enterprise portfolios to said goals, defines operational behaviour paradigms to meet those goals, and generally makes or breaks an organization's ability to deliver through their leadership style and the other leaders with which they surround themselves in the name of, ironically, leadership.
At the project and program level, it makes sense to understand risks and have plans/theories to mitigate them. Issues? Remove them. Dependencies? Accept them where necessary, change them where possible. Task-based effort estimates and roll-ups to larger deliverable units of work? No problem. Reporting, status reporting and the like? Sure. So what's the problem?
The problem lay in the employed mechanics of controlling the delivery versus the deliverables and throughput flow. It is a classic paradox. The mechanics employed to control the delivery actually break the deliverable.
Theory of constraints, lean manufacturing, kaizen, kanban, just in time and any other flavour of manufacturing efficiency you'd like to throw in there are built on the premises of:
- maintain system level flow; and
- eliminate anything that inhibits or otherwise precludes system level flow.
Were leadership to, through frequent iterative practice, constantly evaluate the system flow looking for process and procedural waste, the system itself would identify those things within itself precluding, inhibiting or otherwise subverting flow. The only reasons this won't be apparent is:
- The evaluators are looking at components of the system, not the system itself;
- The evaluators are protectionistic believing the system problems are with other people's components.
Take the principles of flow already achieved in successful assembly line environments and apply the idea of flow to software. Look to Henry Ford, Taiichi Ohno and Eli Goldratt to understand assembly line flow. Only then are you prepared to abstract these concepts into the software realm. Prepare yourself, they look the same. They aren't. And the leaders, managers and project managers who can't see this will contribute, in the terms of successful manufacturers, waste.
Let's talk about iterative, autonomous software evolutionary behaviors for a moment.