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.

To the Cloud, Gently

As a member of Generation X (born in the early 70’s), and as the middle child of three, I have come to accept, perhaps even embrace, my  professional positioning between the Baby Boomers and the Millennials – the two that really matter (IMHO) in the socio-economic dynamics of the day. The spending power of corporate leading and actively retired boomers, coupled with the almost innate “wiredness” of today’s young adults, bodes for a future of even more integrated technological experiences across platforms and devices that actually do make life easier and better.

I am in-between. I have a certain old school way of thinking and approaching life that comes from being a “tween” during Reagenomics. I remember, with fondness btw,  first getting cable TV  and sitting on the floor up close to turn stations because the 33 channel plastic slide box was tethered to the TV by a 3 foot, brown plastic cord.  In college, I first saw the internet in action when a friend placed  his telephone onto a physical modem to “log-in” and register for a class. The rest of us stood in line.  I remember what it was in the human disposition that compensated for things later to be replaced by conveniences in personal computing.

On the other hand, greying temples aside, most people mistake me for being 10 years younger than I am. For whatever reason, my personal and professional lives have kept me in touch with what is going on at the edge – at least in terms of technology and the way it is affecting social dynamics. Beyond being a consumer, I have been an interactive production lead for over 10 years. My experience is from the data management to cross-platform front end-interactions and content.  I understand the power of full,  seamless connectivity – even though a part of me remembers a different way of being.

It is because of this perspective that I often provide professional value  by bridging the gap between the established way and the innovative way. The ability to see and appreciate both sides helps me create win-win scenarios that make sense to varying stakeholders who differ in, amongst other things, seniority, professional role and generational perspective.

The practical difference usually manifests in a decision to adopt a cloud based, SaaS application to replace client side installations of business application software.  This also means paying attention to which cloud solutions offer the best potential integration with other applications to promote ultimate connectedness.  It also shows up as analytical decisions of what success metrics can indicate positive ROI from social media campaigns, and how to define lifetime value for CRM marketing to a new breed of wired consumers. From the strategic to the tactical,  I constantly find myself in the middle of decision making processes that pit corporate momentum against the ever changing interactive landscape.   This is also the case with a number of known advertising agencies that started off in print and are now “doing digital.”

But don’t get me wrong, this is not a case of “out with the old, in with the new.”  As was true in any generation preceding ours, the younger must learn from the older. Wisdom of experience is not a quaint bygone of the pre-Ipad  era, and sometimes the best solutions, whether they use technology or not, are best assessed by people who know what it means to only know life under the cloud. All you need is someone who has been there and back.

Back to the Client Side

On the eve of starting a contract with the national Juvenile Diabetes Research Foundation (www.JDRF.org)  as a PM  on a number of application customization and roll-out projects, I am struck at how genuinely excited I am to be once again plying my craft on behalf of a client organization, as opposed to a service related role defined by developing solutions as an agent for someone else. While I will miss the intensity and dynamic energy of the agency environment, I must admit a sense of eagerness to once again work from the other side of the fence.

I am also thrilled to have a second opportunity to approach the challenge of integrating  multi-channel constituent information for a caused based organization functioning at national and local levels. [I played a similar role for JFNA (then called UJC) in 2007-2008]. It is interesting to see how the technology leaders of a few years ago have developed, and how the understanding of relevant best practices have evolved. I look forward to getting back into the mix.

Long standing charities have  engaged in direct response donor relationship marketing for decades, developing personnel and data management processes to support mail, telephone and, more recently, email marketing. The convergence of constituent relationship data coming from so many sources, including event attendance and volunteer participation, has pushed the flexibility of the standard database technologies deployed in the 90’s and 2000’s. Compounded by a whole new set of interactions from organization sponsored social web activities, effective and efficient data management for these large charities is a major challenge.

There is an allure for interactive project managers and producers (well, at least for me) to work on the jazzy front end design applications, such as online community portals and killer ipad apps.  As I concluded in an earlier post (The Other CSI Myth), the effectiveness of even the most creative and innovative interactive strategy is only as good as what goes on behind the scenes and the data level. Admittedly, a few years ago this was a black hole for most of us working in the IT management of non-profit organizations in the then current state of web technology.  Only a few years later, it seems the main players have kept attacking the problem, and the maturation of partnerships between applications like Salesforce and Convio have closed the gap considerably.

Success in this arena will still necessitate an elegant orchestration of multiple software services, third party vendors and significant infrastructure choices – and by no means will it be easy. I am ecstatic to join a strong team at the JDRF with an ambitious vision of how interactive technology can facilitate deeper relationships with constituents and stakeholders of all types.

If anyone has related experience or insights to share, please post below.

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!