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.

It doesn’t always translate off the screen…

A common circumstance in creative and technical production environments is that the overall coordination between the various functional teams doing the work usually ranges from haphazard to chaotic.  Between account, creative, copy, tech – let alone BA, SEO and other niche specialists – there is often an overall sense that no one really knows what’s going on. Ironically, even teams dedicated to user centered design are often unable to create systems of information sharing and group collaboration that are user friendly and effective for themselves.

Many believe that the harnessing of team chaos is the project manager’s job, and if the team is out of synch, the PM is largely to blame. The underlying premise is “no matter how dysfunctional we are, you need to make it work for all of us.”  Admittedly, there is truth to this sentiment – after all, it is what we signed up for. However, there is an underlying factor that often contributes to the original dysfunction, and bringing it to light might help teams solve the issues of low coordination, low productivity and low morale.

The prototypical agency model is a matrix organization that has a warp and a weft of functional and project operations.  Team members like art directors and technical developers are pulled side to side by project managers, as well as up and down by their own department managers. This dynamic creates tension and ambiguity in terms of priorities and procedures.  Management will often take a top-down approach – speaking to all groups individually, shuttling complaints and issues back and forth, and mandating new “processes” that are disjointed, out of context and only nominally useful.

The key, IMHO, is to recognize the challenge of the agency matrix environment and solve coordination issues as if it were a UX design challenge (which it is…). The project managers can not figure out on their own how everyone else wants to communicate and collaborate, just like a they would not decide where to place information and links on a web page.  Determinations of meeting schedules, status updates, project plan formats, etc. should be made with the user (AKA team members) needs in mind, and not just what the PM states is “the process.”

The discovery into the user needs must take into account that the users, in this case, are simultaneously members of a project team and functional department, and sometimes those roles might carry contradictory preferences and requirements. While simpler to do, ignoring this fact only creates more imbalance and disharmony.  Getting functional leadership and project management onto the same page to create a holistic salve for agency dynamics is easier said than done, but recognizing the implications of being in a matrix structure is a good place to start.

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!

Planning in 3-D

Most of my colleagues  know that I am a  big fan of Clarizen project management software, so much in fact that I offered unabashed praise in a case study-cum-advertorial last year. There are a number of reasons why I love the software – user friendly interface, robust functionality, excellent support & training, etc. – but the Clarizen feature that really won me over is a fundamental paradigm shift in how I approach project planning, especially the creation of team work plans, whether I am using Clarizen or not.

Primarily, this paradigm shift is linked to an alternative usage of “milestones” in project planning. The general definition of milestones, a series of markers placed along a path at mile intervals, is consistent with how milestones are used in Microsoft Project. The milestone  is a no-time marker that the project progress has reached a certain point along the way, much like a driver keeping track of how far down the road he/she has traveled. It has no duration or resources attached, and represents an intangible point in time that has no work dimension in of itself.

Clarizen takes a different approach to using milestones in project plans, even if it diverges from the traditional “marker along the way” definition. A milestone in Clarizen is more like a 3-dimensional building block that contains any number of activities and tasks. When the activities and tasks are complete, the milestone is complete. Thus, complex projects are  made up of multiple milestones that are completed along the way, eventually yielding a finished project.

Semantics you say? I beg to differ for the following reasons:

1. Thinking of milestones as activity blocks to build  (or buckets to fill) is a concrete visualization that helps team members and stakeholders grasp the structure of the project plan.  It is a sort of like a high level WBS for the execution phase that can be expressed literally and visually.
2. Different resource sets can be assigned to different milestones, so everyone can focus on the part of the plan that is most relevant to them, while delays or issues can easily be pinpointed to the appropriate team members.
3. Top down planning, including work hour estimation, is easier, faster and more accurate when there are discrete project chunks to assess instead of looking at the project as a whole.
4. Libraries of common  milestones can be saved and used for new project planning.
5. Milestones can be compared across projects and clients to assess production performance and efficiency. This is particularly helpful in agency environments.

Really, I could go on and on. Any production / development environment handling multiple projects at once could benefit from this 3-D approach to project planning, IMHO.  It is a simple shift that can align estimation, scheduling and reporting regardless of the software being used to manage projects. However, my props go to Clarizen for building it into the fabric of their tool-set.

Home School Project Management 101

Since we are homeschooling our children, I have a fun opportunity to add “basics of project management for elementary aged kids” to their curriculum. We recently did an assignment / activity around organizing a complex shopping trip as a distinct, temporary endeavor with requirements of efficiency and quality.

Our back to school shopping usually overlaps with making sure everyone also has appropriate clothes for the Jewish High Holidays, such as suits, dresses and other dress clothes. Additionally, this year, we were preparing for an October family wedding. With 5 kids to shop for, and some old enough to care about their own style but none old enough to drive, there was a lot to do.

In the midst of the flurry of gathering the requirements – which kids needed what stuff – it occurred to me that I could use a formal plan to manage the chaos of figuring out which kids needed to be taken to which stores, scheduled according to  the sporadic windows of time my wife and I would have available for such activities. 

I gathered the team, my wife and kids, and led them through an “activity definition” exercise that produced an output that we then organized into an actual WBS. This became an input to a series of shopping lists matching kids to stores. We then organized the project milestones by store and matched store by location to parental location and time windows. Parents knew ahead of time which stores to go to on which day of the week, as well as which kids were coming and what exactly needed to be bought for each – information provided by the kids themselves and organized into lists.

Using a WBS framework for helping my children in school has many applications. One child was struggling to get started on an English writing assignment, and I followed a similar process to help him organize a content plan to base his writing from.  It’s really cool to see fundamental methodologies work at the  most elementary levels.

“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.

“No TEAM in TEAM”

One of my most maddening PM realities out there is the common agency matrix situation where projects are run without clearly demarcated teams. It is not necesarily true at the larger agency level – although in digital I suspect its more than assumed, but the boutique to mid-size shops often have creative and technical resources acting as chef’s in a restaurant kitchen, filling orders on tickets without looking up to see which waiter and customer was doing the ordering. They and their work are managed solely by their departmental, functional manager and the PM, no matter how senior the title, is reduced to a de-facto project coordinator function.  The resultant reality is a project without a  team identity. IMHO, this is a huge detriment in running a project based production and development  operation.

SDLC vs. Interactive (part 2 of 3)

In thinking about this post I realized that there are so many directions to go in, such as methodology comparisons, stakeholder dynamics, the role of creative subjectivity in requirements definition and testing, etc. I do want to stay focused, however on the basic question of comparing software development to interactive development.

I met with a team yesterday in the midst of a website redesign project who was looking for a PM to replace a last-minute drop out. During the course of the discussion, the QA lead (coming from a software dev background) asked if I thought they should follow standard SDLC practice when building the site.

I asked back which part of the cycle would they consider NOT using…planning? analysis? testing? Once again, OF COURSE a system design framework can be applied to interactive technology development as it is technology development. It could also be used, and is used in relatable paradigms, to manage marketing and communication initiatives.  The trick is integrating the parallel management systems that these disparate  business functions use to implement their strategies. One example of where the rubbers meets the cement, IMHO is the relationship between front end and back-end development as the final and true implementation of interactive productivity, the place where  requirements validation is more than a set of technical protocols. How much work and re-work is logged becaue of disconnects there? In my experience, quite a bit.

A significant, and obvious, obstacle in implementing one single methodology to encompass all interactive (eg. website) production and development is communication. The words used and the concepts they conjure are different for front end and back-end team members, let alone their supervisors and senior stakeholders.

So what to do???

SDLC: Software Development vs. Interactive Marketing (Part 1 of 3)

As a digital project manager who came up the ranks through marketing and web, I am often asked my opinion on applying standard SDLC (system design life cycle) methodologies to web development. In other words, can the same PM processes that manage, let’s say, a large technical database project be used for managing a large advertising website?

As I’m sure you can guess, I am not the first to try and answer this. Check out http://www.learn.geekinterview.com/it/sdlc/sdlc-web-development.html for another post that seems to generally say “yes, they are related.”

The post above does not satisfy me. It’s too simplistic and doesn’t get at the heart of the issue. The primary difference between software and interactive marketing projects is not the project itself. Of course SDLC can be used to manage system planning, architecture, execution, testing and maintenance. It’s not the tasks being performed, its the PEOPLE doing the tasks that differ. Marketing projects introduce a new layer of team members and stakeholders, ones with subject creative ideas and preferences. The real question is can SDLC be used by interactive marketing teams like it is used by traditional software development teams.

This leads to an obvious discussion of different methdos of SDLC – waterfall, spiral, agile, etc – and how each rates as a possible method for each type of development. Stay tuned for part 2!