Waterfall and Proud of It

I know that, as a methodology, waterfall development has many shortcomings. On the other hand, from novice to expert, it is the most basic and most commonly used system for organizing group work efforts.

There are multiple styles of agile alternatives, but despite the passion of their adherents, trends like those are, and will remain, “counter-establishment” minorities in digital production and development environments.  Among other obstacles, the required client buy-in and partnership model for true agile development is culturally too far away.

A key to maximizing accurate project planning, especially in multi, interdependent waterfall project scenarios, is not only marking obvious and hidden dependencies between related projects and activities, but also to build project plans that make the right connections to effectively anchor baselines and be able to assess impact and change.

The ability to properly  structure  milestones, decompose activities, and connect dependencies is a skill that goes beyond proficiency with Microsoft Project. It requires a broad, big picture understanding of how all the moving parts are really part of one.

Source: fantastictravelling.com via Melissa on Pinterest.

PMO – Project Management Operations???

Projects are, by nature and definition, temporary in duration. They are completed and closed, making way for new projects in the queue. This is a key distinction between “project management” and  “operations management” (like manufacturing or accounting) that chug along in an ongoing fashion. Thus, project management methodologies, like PMI, are tuned to the ebb and flow that churns projects from initiation through closing.

In matrix organizations, however, where project resources (including the project managers) are often committed to many projects at once, responsibilities to various initiatives are typically disconnected from the larger project life-cycle, and the work is done in an “ongoing” fashion.  For example, a patron’s order in a restaurant, from drinks to desert, is a temporary “project,” yet to the guy making the sushi or the woman making the pasta, it’s just one dish after another after another.  The people in the kitchen produce operationally, even when contributing to a temporary and specific outcome.

One way larger organizations answer this challenge is through the PMO – the project management office. The PMO is a department or group within an enterprise that defines and maintains the standards of project management processes, attempting to standardize and introduce economies of repetition in the execution of projects through formalization of things like documentation, templates and metrics. The PMO seeks to manage ongoing projects as projects in a portfolio, even if the resources themselves are heads down making sushi.

Like a military HQ behind the lines, the project management office gathers information from all projects for high level analysis and strategic decision making that is sent back down to the field level in the form of directives and protocols. Project managers are usually the communication liaison between the teams and the office.  The overall value of the project management office is oft debated, and it is not my intention here to criticize or defend. Rather, I am pointing out the rather top-down nature of keeping multiple projects on track where resources in the field may not even see themselves as part of a specific project team.

In my experience with medium size organizations handling multiple projects at once, the project management office is not a viable concept. Everyone wants good processes that promote efficient performance and quality deliverables, but the idea of a distinct office of project managers dictating formal process from afar is an anathema. Planning outcomes have a short shelf-life of relevance, and by the time the PMO processes and turns around a strategic decision, the reality on the ground has usually evolved into something else.  Resources doing the work, especially in digital and marketing arenas, can’t help but question the intelligence of the directives coming down from on high – and the project managers are usually caught in them middle.

Because of this, I have been exploring a framework of multi project management that seeks to systematize project operations through a combination of processes and schemes that build efficiency and quality into activity areas at the project team level. This means an organized framework where resources, even those working on multiple projects at once, are able to do their work in context of the larger initiatives. It also means a higher emphasis on strategic thinking on the part of the project manager, ensuring each project is progressing according to organizational objectives. Another key component is the recognition that  project planning is rarely completed like the top of a waterfall, and change management is really a convergence of planning and execution during the execution phase.

I hope to expand upon this model of project management operations in future posts, especially as it applies to multi-project environments. If you have specific questions or comments, please let me know!

“I hate process!”

Another challenge for any size production and development environment, especially in a matrix organization, is the question of commitment to meaningful process improvement and optimization. There is an added layer of obstacle if the organization is not large or mature enough to institutionalize operational mandates that are larger than the “thinking du jour” of the business owners, especially in creative shops where the major stakeholders tend to be generally adverse to overtly imposed processes.  Even processes rooted in best practices tend to run contrary to some peoples’ natural way of working and thinking about their work – therefore are known to publicly exclaim “I hate process!”

The obvious key here is transparent process. Making efficiency and quality process adjustments without certain team members even aware they were implemented. Subtle, nuanced – even elegant – refinements that meet the path of least resistance from project and functional colleagues. The problem is that  improvements are often needed to fix real production / development issues that are not so subtle, and real change needs to take place.

Cost saving tools like templates and forms are only as good as the process they come to support. They are not, and should not be, goals in themselves. Rather, they are the yield of issues identified and resolved.

Bottom line is that a PM as a change agent necesitates an organizational commitment to change. As goes the well known addage, the definition of insanity is doing things the same way and expecting different results.