A blog by the Brick Factory The Brick Factory
project management pitfalls

How to avoid three common project management pitfalls

A few weeks ago I wrote a post about how important it is for project and account managers at web development firms to have empathy.  If you are able to see the world as your client does, chances are you are going to do a great job for them.  You will be able to anticipate problems before they happen.

As a follow up, I wanted to share some real-world examples of client communication problems we’ve run into at the Brick Factory and explain how they could have been prevented.  The underlying theme is that most issues can be prevented with good communication that comes from understanding.  

(1) Hidden Requirements

Project management problem

You have been working on a site redesign project for three months and are a week from launch.  While reviewing the beta version of the site, the client points out that a members-only section that was present on their old site is missing and must be built prior to launch.  This is the first you have heard of this feature.  Your launch date is now in peril and you have to have a difficult conversation with the client since the work isn’t in your original Scope of Work.

How it could have been prevented

No matter what project management methodology you use (Agile, Waterfall, etc.) or how small a project is, every engagement should begin with a discovery phase aimed at surfacing requirements.  Write out the features and functionality of the site/feature you are building and get the client to review and approve to make sure nothing is missing.  

Skipping the discovery phase is sort of like heading out on a cross country, family road trip without a map or GPS.  You will probably get there eventually, but it is going to take a long time and there will probably be tears.

(2) Misinterpreted Designs

Project management problem

Your team has produced a series of design comps for a new site that you are ready to show the client for the first time.  Language and photography are still being finalized, so you use placeholders in the initial comp.  You send the client the designs via email and don’t hear back for a week.   When they finally do get back to you most of the feedback is on the placeholder images and text, and it becomes clear that the client is confused by parts of the interface.   You are able to clear up the confusion with a phone call, but you have wasted a week.

How it could have been prevented

This one is pretty simple: you should always present your first big design deliverable either in person or via a screen sharing service where you can control the experience.  You should only send a link to the design after you have presented the work first.

By presenting the work you are able to explain the decisions you made, fully demo how the interface works and clearly define what kind of feedback you are looking for.  It gives you the opportunity to make sure your work is properly understood.  No matter how thorough or well written an explanatory email, it can’t take the place of a conversation.

(3) Misunderstood Deliverables

Project management problem

You create a series of wireframes for a new website you are building.  The wireframes are in black and white, and intended to demonstrate overall page structure and content priorities.  After sending the wires to the client, you get a short response asking why the new site design is completely black and white.

Later on in the project, you send the client a complete, full color design comp that is in PSD format and optimized for widescreen desktop computers.  The comp is posted in Invision so that the client can see what it will look like in a browser and provide feedback before you build it out in HTML/CSS/JS.  The client calls you five minutes after receiving the comp in a panic, asking why the new site draft doesn’t work on mobile phones.

How it could have been prevented

In both of these scenarios the client misunderstood the deliverable you sent.  In the first scenario they thought the wireframe was a full site design and in the second scenario they thought the design comp was a full working site draft.  

If you are like us, your clients are smart people who are true experts at their jobs. But for a lot of them web development isn’t their primary job.  They count on us to walk them through the process of building a site.  It is a mistake for us to assume that all of our clients know what things like wireframes, design comps, mood boards, prototypes, etc. are.  

One of the first things a project manager should do when onboarding a new client is explain the process that will be used to build the new site or feature.  Walk them through each of the deliverables you are going to produce in detail, explaining what they are for, what their limitations are and what type of feedback you are looking for.  I know this sounds obvious, but I personally have skipped this step and ended up confusing the client more times than I care to admit.


Empathy: a project manager’s secret weapon

Our Brick Factory team recently moved into a new office in the McPherson Square area of Washington, DC.   Our new space was previously occupied by a law firm with an affinity for wood paneling, ship drawings and 80s style carpet.  Thankfully, as part of our lease we were given the opportunity to completely gut the space and rebuild to our exact specification.  This involved a pretty extensive construction project with deadlines, budgets and a team of contractors.  As the client on the project, my job was to oversee the process and to make a million small and large decisions.

I had never been involved in a construction project before and it was quite a trip.  I pretty much felt confused and incompetent the entire time.  I didn’t know speak the language or truly understand the process. I asked many, many stupid questions and had to have things explained to me 2-3 times before I was able to “get it”.  I lived in fear that I would make an expensive mistake.  Despite my extremely shaky performance, the new office turned out great due to the wonderful job done by the team we worked with.

Managing the construction of our new office increased my appreciation for our clients.  Being the client is hard.  By playing the role, I was able to gain a greater understanding of the stress and emotions our clients feel when working with us on web development projects.

At the Brick Factory our clients are smart, busy people who spend their days fighting important policy battles, running successful businesses and/or trying to make the world a better place.  Their jobs are hard and stressful, with deadlines and goals they rely on us to help them meet.   While the web is critical to what they do, building websites is rarely their primary job and not all of them have a deep understanding of the web development process.  

In order to do right by your client, I think one of the most important traits you can have is empathy.  There is a lot of good content on the web about empathy (go watch this video right now), but this definition sums it up pretty well:

The ability to step into the shoes of another person, aiming to understand their feelings and perspectives, and to use that understanding to guide our actions. 

If you think about it, that is a pretty good description of what a project manager does.  If you are able to see the world as your client does, chances are you are going to do a great job for them.  You will have a deep understanding of their needs, and will be able to prevent most problems and resolve the ones that do pop up quickly and amicably.   

While certainly incomplete, to be an empathetic project manager you have to do the following:

  • Understand your client’s background and experience level.  The way you work with a client that is managing their first web development project is going to be fundamentally different from a client with a wealth of experience.  Understand your client’s experience level and adjust your process accordingly.
  • Know how your client likes to work.  Some clients want to be involved in every decision while others want to provide overall direction and let you handle the details. Sometimes it is a mistake to ask for feedback too often. Other times it is a mistake to not ask often enough.  If you understand your client you’ll know what to do.
  • Get to know your client’s company culture.  Is the organization fast paced or laid back?  Who does your client contact report to?  Does your client email you late or night or just during the business day?  Understanding the environment your client is working in will help you provide them with better service.
  • Understand what is keeping your client awake at night.  Is there a big conference they are preparing for?  A vote on a big bill that is fast approaching?  A fundraising number they need to hit?  If you truly understand the client’s pain points you’ll be able to provide better counsel.   
  • Always figure out the “why” behind a request.  As a project manager you have undoubtedly received an out-of-the blue request to move a deadline or to implement a new feature ASAP.  Take the time to understand the context.  This will allow you to distill the request down to its core, providing  you the information you need  to solve the problem.  
  • Actually talk to your client now and then.  A lot of work today is done via emails and collaboration tools such as Basecamp.  Make the time to talk to your client on the phone and/or in person now and then.  You will undoubtedly learn something you wouldn’t have known if you’d stuck exclusively to electronic communication.  This will build connection and understanding.

When you are a project manager at a web development firm, it is very easy to turn into a robot programmed to complete tasks as quickly and efficiently as possible.  But being able to put yourself in the client’s shoes is just as important as efficiency.   Indeed, empathy is often the difference between a great project manager and one that is merely good.


In Defense of the Single Page Website

Like all things that become popular and overused, there is a backlash  against the once revered single page, long-scrolling bootstrap template website.  It is safe to say that a good percentage of the design community is eager to bid it farewell.  While I am as bored as my counterparts with the army of single page sites that all look pretty much exactly the same, I’m not as quick to dismiss the entire concept as passé.

single page site layoutFrom a design point of view, the concern is the saturation of bootstrap style layouts for every agency, PR shop and freelancer needing an easy template.  A design can lose its impact if visitors have seen it a million times already.  Hero image, intro statement, services icons and links, news and blog, CTA and footer. Mix and match if you wanted but most take the template straight out of the box and call it a day. It is bought, used and copied because it works. A one-person shop can produce work as  polished as a a lot of decent-sized agencies.

The single-page layout can still work well, however, if you approach your single page website as a completely fresh design build. The fact that the page can be simple to lay out doesn’t mean it should be considered a template. If anything, with the abundance of single-page scrolling sites, designers need to give more care in creating original designs within this framework.

The reasons a long scroller still gets plenty of play here at the Brick Factory are:

Immediacy.  A single page scroll eliminates confusion as the user interface (UI) is immediately understandable.

Mobile. Obviously, a single, long page scales to mobile fairly easily.  I don’t have to spend time developing custom layouts for different phontes, tablets, widescreens, etc.  This cuts down design time and results in sites that work well on all devices.

Parallax Scrolling is still kind of cool. If you have professional photography, single page sites can still look remarkable.

Scroll-activated animations and transitions. These events can work within a variety of layouts, but we find they work best on a vertical scroll and can become a meaningful component of the narrative.

Maps, Graphics, etc. Integration of graphical elements presents less of a design challenge when you have the luxury of a blank canvas to work with.

Less distraction. For some sites we build, a singular narrative is preferred.  This is particularly true for focused sites that have one overall message to convey or call-to-action to complete. A long scrolling site is perfect because it allows for a distraction-free user experience.

Modules. If you design systems rather than pages (cough, like we do, cough), then a single, deep site works perfectly and can be reworked easily through rounds of internal and client edits.  Components can easily be moved around and reused.

In summary, although a bit labor-intensive on the front end, if designed with a creative approach one-page scrolling sites can still work.  A conscious effort to create a unique design that doesn’t look like every other site on the Internet just needs to be made.  If you do that, the single page site can provide a friendly, consistent experience for virtually all levels of user on just about any device.



Drupal Blog Post Header

A step-by-step guide to configuration management in Drupal 8

One of the best improvements in Drupal 8 is the new configuration management system. This post explains how things have changed from Drupal 7, and provides a step-by-step walk of Drupal 8 configuration management.

Configuration in Drupal 7

If you’ve spent much time site building or programming in Drupal 7, you probably have worked with the Features module. This module was originally created as a way to package config to easily create reusable functionality on multiple Drupal sites. But it evolved to be used for a much larger task: deploying configuration that is stored in the database between environments for the same site (commonly pushed to a code repository like git).

Our Brick Factory team started using Features for our Drupal 7 builds around four years ago, and it has saved us a bunch of time and headaches.  Before Features, we had to remember the configuration changes we made on the dev environment so we could manually re-apply them on the staging and live servers (which is loads of fun!). Features made it very simple to do this and not have to remember all of the config changes.

The Features module did fill a huge need, but it also came with some unique problems:

  • Learning Curve: The learning curve was steep. For us to get comfortable with the concepts and the flow, it took around a year of experience using the module across different projects.
  • Organization: It seemed like people had different ideas in how Feature modules should be organized across the Drupal community. From my experience, I think grouping into small feature modules prevents a lot of issues in the future, especially with large sites.
  • Overwritten Status: The overwritten status could mean multiple things. Did someone update config on live manually? Or did someone push changes to the feature modules and forget to revert? What was changed? This led to a lot of confusion.


How We Built It: International Youth Foundation Annual Report

A few weeks ago I wrote a post about changes we have made to our Brick Factory design process over the last few years.  Check out the full piece if you have time, but the gist is that we haved moved away from designing pages and towards creating systems.  We are trying to design overall styles and repeating elements that make up the pages, instead of the pages themselves.

Showing is always better than telling, so I wanted to write a follow up post using the Annual Report micro-site we built for the International Youth Foundation as an example.  What follows is an explanation of our design and build process for the project, with actual deliverables included to make things more concrete. (more…)