Category Archives: Project Management

Managing Up, Down, and Sideways by Breandán Knowlton

At the Digital PM Summit this year, I had the pleasure of sitting in a “conversation” session with a bunch of smart folks talking about “Managing Quality In Development Teams”. I could also tell one of the contributors in the corner really knew his stuff and had come from an interesting background. Little did I know, I was sitting in his session the next day titled “Managing Up, Down, and Sideways”.

Breandán Knowlton presented a unique combination of concepts that I’ve taken home to the team (and to heart) when approaching conflicts (or really, any dialogs) with our interactive projects and clients.

I’m sure most folks have heard about “managing up”, or put simply, doing the things that will make both you and your boss (or client) happy. Pro-actively providing status updates before they ask for them, finding what their goals are and aligning your own to meet theirs, finding their values and cater your approaches to those. This all makes sense when applied smartly and is something I know I could think about more often when working with clients and stakeholders.

Knowlton’s talk on “Managing Up, Down, and Sideways” put a kind of spin on this and introduced a theory of four relational models used “to generate, interpret, coordinate, contest, plan, remember, evaluate, and think about most aspects of most social interaction in all societies.” If it’s good enough for all societies, its probably good enough (and applicable) to leading successful projects, no matter the size or shape.

I’ll summarize the four elementary models:

Communal Sharing: you operate with common respect or values, love for the project or process, take collective responsibility towards success, etc.
Authority Ranking: respect is geared more towards hierarchy and class structure, prestige or superiority exist here.
Equality Matching: there is an unbalance perhaps in skills or knowledge and work to share, process exists to keep balance of opinions or efforts, respect may be more towards rules and regulations.
Market Pricing: standards around cost-benefit come into play, efficiency and effectiveness may be measured, those measurements or ratios are viewed with social meaning.

Thinking about these models and how they can apply to project management should become clear. From here, Knowlton had us all run through an exercise:

Think about a situation (a project) and then a conflict. From your own perception, what was your priority, what were you thinking about, talking about, experiencing, etc. (and did one of these social models apply to your thinking)?
From others’ perspectives, what were their priorities and perspectives, (and what model may have applied to them)?
Once you came to a resolution (it may or may not have been positive), what was the result, did you end up appealing to the same model, or did you find yourself (in hindsight) and your stakeholder(s) applying different models to the situation?

I thought about a project where we were building a complex network of applications and websites that all had to interoperate for a very large internet company. The project was to span nearly a year, had many requirements, plenty of details to review and keep track of, and we were nearing a point of getting final user acceptance and testing completed.

From my perspective, at this time (maybe 10 months in), a new stakeholder with new priorities was introduced into the project (as a newly hired senior executive). Some newly stated project priorities from that stakeholder meant the work to date would need to be re-evaluated and substantial new efforts (costs, time) would be required.
From their perspective, as an executive responsible for budgets, priorities, etc. this was a big project that didn’t meet obvious unstated goals, it had become more complex than needed to solve some immediate-term goals, and was at risk of not being a meaningful contribution to the organization.

Looking back, a lot of the work and interactions to-date appealed to the Communal Sharing model (we created this project together) but the introduction of a new stakeholder certainly appealed to Authority Ranking. Ultimately, we took the discussion to a common level (Market Pricing) and, in short, discussed the cost-benefit to undoing parts of the project (which also appealed to Authority) and we jointly decided to end the project, hand over our work performed to-date and allow them to continue in their preferred format (Equality Matching).

Thinking about a project’s various stakeholders, their perspectives outside of your way, and then applying the “Relational Models Theory” can likely both describe and allow you to overcome challenges, have more successful exchanges, or simply understand where a situation may have turned.

Content Before Design: a shift in how to manage web projects

10 Replies

I like to joke that Happy Cog and the people that work for (and with) them sometimes act as the research and development arm of the digital / interactive project management industry.

A novel idea, writing content before design, discussed by Steph Hay at the inaugural Digital PM Summit is crazy (good) enough it could completely transform digital design projects for the better. As with any good R&D process, we may be in the early days of a complete shift in thinking (like mobile-first design has been in the past few years). Or, we may forget this entirely due to lack of buy-in and ability to ‘grok’ an alternative approach.

That said, I recommend all digital project managers and organizations looking to do an online project in the near future and consider this approach and continue testing this approach and the resulting effects.

Approach

Beginning a project by talking about the audience(s) and precise interaction(s)s that currently do or need to happen means getting past guessing about what content elements and design templates need to be “designed” while still embracing ambiguity and figuring this out as you (or your client) go through the process.

Clients often want to see a layout or a concept, or a list of content types before “plugging in” all the final copy text, words, and so on. Once we “see it” we’ll make the content work to match the discovered goals of the design, right?

Writing content first means zooming in on a single piece of content, say a product description page, and writing precisely what needs to be on that page. Then stepping up a level, and repeating the process, and then moving sideways across all unique items in the project to see what patterns, unique elements, and hierarchy emerge.

This process allows the designer to then create a model that best fits the content presented and makes their job easier (and more successful). It could mean a designer will realize a call-out box design element is the best method to prioritize a testimonial on the page versus designing a page concept with testimonials included when the client has no real customers (or testimonials) yet. It could means noting the whimsy in the ‘voice’ on the page should be matched by the stylistic elements surrounding the page.

Results

Steph walked through a recent successful website re-design project she led that followed a content-first approach and I’m convinced. Both you and your clients should realize the benefits to taking this approach and see if its worth going down this content creation path up-front:

Increases organizational capacity: if your client goes through the exercise of writing content up-front and making all the hard decisions, this then allows them to work in parallel while you begin the design process.
Prompts for stakeholder involvement earlier: often when a design concept is presented with ‘lorem ipsum’ placeholder text, “higher ups” do not want to be involved until things are closer to completion so they can provide meaningful feedback. Having content in place flips the switch sooner to allow looking at closer-to-final artifacts.
Gets to decisions quicker: when needing to provide feedback, a mental disconnect can happens if you’re able to skim over the placeholder text and simple assume the “right” content will fit naturally. As you write content, as you define the content and display models, the two convene sooner and allows for more acceptance, revisions, and testing along the way.

A traditional design process without content written first means you can’t discover what’s needed until you realize its missing.When a discovery like this happens so far into the implementation process it can de-rail a project with rework, missed timelines, blown budgets, and disappointed stakeholders.

Steph has a framework on how to begin a project with content discussions first that I encourage project managers to review and consider.

I’d also recommend comparing and contrasting this thinking to the traditional design approach found in typical interactive projects and considering the pros and cons of each.

Reviewing the “Design Process” for Project Managers

3 Replies

Project Managers, if you’ve been working in the web and “interactive” design space for a while, you may not realize how much you know about the design process.

The thing is, we’ve likely absorbed and learned these things over the months or years. Our clients have not had the benefit of the experience. Here are some things we know, presented by Jared Ponchot at the inaugural Digital PM Summit, and could likely be better educating our clients around:

Design is not just “look and feel”, design is the process of imposing meaningful order to content and interactions.
Realize the design process is not unique to our industry and is, for good reasons, similar across industries. Look for metaphor in how cars are made, houses are built, and so on.
When designing, we should start to aim for “living” deliverables. It allows for tacit, ongoing approval and discussion of priorities. The ‘big reveal’ (Mad Men style) doesn’t always make sense and allow for dialog around design.

Put simply, design is the intersection of purpose, content, and style.

Purpose (why?)

Design is the process intended to figure out how we should best solve the stated problems (need more customers, want to inform the public, etc.). Fleshing out those problems, the purpose, is key to a meaningful design process.

Keep asking why and get to the root issues. Ask more “what will that get you”?

If you tell me you want to build a bridge, I will ask why? You say you want to get across the river. Why? You need to get to work on the other side. Why? Because the fields are on the other side. Why do you work the fields? Over time, instead of building a bridge we may set out to solve different problems than originally proposed.

The who, when, and overall context can affect responses to probing design questions.

Speaking with a team may yield different answers than working individually or separating the bosses from the employees. Sitting and looking at inspirational websites together may allow for more conductive exploration than on a phone call.

Ultimately define purpose statements that serve as the goals to tie decisions back to.

If you don’t know which direction you’re headed (“more customers”), how can you know if you’re actively working towards those goals?

When working with clients, being able to point each evaluation, decision, question back to the goals is the best way to ensure the design process has a good chance of resulting in success.

Content (priority not position)

Two excellent tools exist to start pulling together the content that will solve your stated problems.

Content Model

There are three things we can capture to effectively design solutions.

Content types: in order to meet the stated goals, what content are we creating, publishing, and making available?
Attributes: for each of those content types, what are the attributes that define them? (title, image, etc.)
Relationships: where and why is the content related? (blog posts about each product)

As you define these, you can begin creating artifacts that moves the design process along in a meaningful way.

Display Model

Describing how the content is presented can be achieved with wireframes, sketches, etc. and is typically what we think of when we think “design” (but as you see, it shouldn’t be the first step in the process):

Sketches and descriptions of the various templates start to demonstrate the priority (not just the position) of content (which was defined because it achieved stated goals). Describing the various components and the hierarchy results in a vocabulary and series of artifacts to inform the final designs.

Style (is not powerless)

This final piece is what may be considered, by most, all there is to the “design” process. Style is not simply preference. A couple points to help explain why style is not the first step and is not a powerless piece (nor the entire point), of the design process:

Color enhances priority, it’s not just a preference. When we propose a dark red button on the sparse, white screen, that color contrasts and demonstrates hierarchy (it is more important). If a client asks for it to be gray, that may not solve the stated problem (“convert more user to subscribers”) and is not just because gray is a “better” color.

Style allows for personality and can make a design more human and connect to a visitor, user, potential client. It helps express a brand and separate a business from others in the space. Picking a “flat” style versus a “textured” style should not simply be a preference.

Aim to seek evaluation against the stated goals and frame the display and style discussions (reviewing mockups, layout concepts) around the purpose and content defined earlier.