Maintaining Energy on Long Projects
If you’ve been in the web business for long enough, at some point you’ll have a story about the project that wouldn’t die. You know, the one with 20 rounds of revisions, features added in development that add a month to the project, and a feature set takes 3 months to agree on? I’m going to be honest and say that I have been a part of several.
At a certain point, these projects will wear on even the most perfectionistic and patient of us all. I mean, how much more juice will you have after the 23rd revision to the home page. It’s pretty hard to keep up your enthusiasm, and I’m a pretty damn enthusiastic guy. There just comes a point where enough is enough, and you just want to see something completed.
In my experience, most “designers” have a shelf life of about 3-4 months on a certain task, after which, they will need to have help to see things more clearly, pass their work on to production, or they will start to get cranky. 3-4 months is about what most people who focus on a certain project can effectively handle. By project I mean an end to end design of a certain piece of functionality or app, as larger sites may have multiple projects. So, for instance, I am a UX designer, my time intensive part of the process on a site happens to take about 2-3 months, and then tapers of to a few hours a week. If it goes on longer, I start to feel it. Once it is off my plate into visual design, the project has new life again and everybody gets excited to see the project alive as visual designers breathe new life into the wireframes.
Oftentimes, we don’t have a choice as to how long a project will take. There may be disention in the ranks,or people can’t agree, or you just haven’t got the right solution. These types of projects drag on, and you just hope for them to end. They loose steam, and creatively start to weigh on you. You loose your confidence in decision making as all options seem the same, and you slug it out until you can hand it off.
So What do you do?
There are some techniques that I use to maintain my own interest in a project, and boost the morale of the team, when everything seems to move at a snails pace. The trick really is to pace the energy of the project. If you get all excited at the beginning and discuss every detail at length in the beginning, by the 12th week, you’re going to be fatigued. I like to break a project into 3 phases – beginning, middle and end. Each phase has things that you can do to boost energy, and get everybody creatively energized about the project again.
The trick with the beginning is to really set yourself up for the rest of the project. Pacing is important, and so is preparation and strategy.
Prepare your strategy well
One of the biggest things that stops projects is a long internal discussion on this feature or that feature based on subjective opinion. I find that it is due to lack of strategy. How many time has this happened: there are 3 ways we can do xyz feature/design, and all of them look good, yet it takes a 1 hour meeting to come to a consensus?
If you’ve done your strategy right, you should be able to refer to personas, goals, and research to make a best guess before yielding to personal opinion. These types of “my opinion is better than your opinion” conversations will kill momentum on a project faster than anything, have the highest potential to create animosity.
Establish your strategy process, make sure that it prepares you for the rest of the project and assists you in your decision making. If it doesn’t, do a post mortem on your next project, and try to figure out what information you were lacking that would have made decision making easier and more accurate. More user research? Usability studies? Feature prioritization? Messaging? How can you create a clearer strategy to help decisions next time.
Set your pacing
A web project is kinda like running a marathon. If you go too fast in the beginning, you’ll tire quickly. Go too slow, and you’ll have to rush to make up time at the end. The trick to keeping energy high is to pace it evenly.
Some projects that I have seen get tiring do so because of the old “sprint” methodology. It is usually impossible to foretell how smooth a project will run, and if it will run according to schedule, but having only short sprints to base timing on may make you spend too much time up front, which can make a project drag. If you set dates, and watch your pace, it will be easier to manage versus making up time at the end.
My philosophy is to do short sprints, being aware of the bigger picture timeframe. Give someone the responsibility of being a “timekeeper” who can push the project along if things get too drawn out. It can be a Project Manager, Creative Director, UX lead, Tech lead or whomever, just not the Product Owner. The Product Owner will inevitably want to tweak things forever. Agree to this up front, get buy-in and set some time boundaries for large sections (Strategy, UX, Design, Development, QA) and some firm deadlines.
The main challenge in the middle of a project is to keep things moving. Nothing destroys project momentum faster than long drawn out back and forth discussion. Back and forth discussion is good for the product, however, too much talk and not enough rock, will leave the key person drained and at worst, discouraged.
Meet frequently for short periods – 15-20 minutes – versus fewer long meetings
In the beginning when there are lots of ideas swimming, a short period of time to discuss a limited amount of items helps prevent long discussions on small topics. Longer meetings, can be very draining creatively, especially when you have a lot of ground to cover. Short frequent meetings are key. If you can’t come to a decision on something in 20 minutes, save it for the next meeting. Agile/Scrum teams already do this as part of their regimen. Making sure that decision makers are part of this will help maintain team morale, and keep the project moving.
When you’re stuck make quick easy decisions to get moving
When a team is stuck on something, it can be very draining to find an answer. For instance, I was on a project where there was research needed by the dev team on a payment system. There was several weeks of research and tested they had to do in order to give us an answer on what payment service we were using. This affected the energy of the team, and at the time, weighed down on the project. At that point, we focused on some other areas that we could get some quick wins on, and that got momentum moving again.
Grab a beer!
Never underestimate the power of good old fashioned bonding. Bonding is a great way to create empathy with your team and to have time to relate in non work mode. Let’s face it, sometimes, discussions can get heated, and if that heat is not tempered, you can start to villanize team members very quickly. Take one day every month to go to happy hour and grab a beer together, and talk about your kids, yoga, hiking, travel, technology, anything BUT your project.
At the end, everybody wants to see the project live already. You can feel the impatience brewing. Product Owners and Designers are pressing to see this live, but even with all the pressure to complete, the product has to be completed strong. I feel our job as Designers at this point is support to our other team members. Our job is “done” and the PSD’s are off our table, but we owe the rest of our team just as much support to make sure the project is completed successfully. I have seen and personally been a part of projects that have failed at this point, due to a lack of support and teamwork with the rest of the team at this crucial juncture.
Support your developers!
Those of us in the design process have long been finished with our portion of intensive work once the project reaches it’s final development stages. Our job in the development phase is to support the developers. Usually these guys get the raw end of the deal. They are the ones who are “pushed” to get a project done with an insubordinate amount of time when everything else dragged out.
How can you support your developers? First, encourage them. Give them praise when they get it right. All too often I see designers critical of developers work, simply because that is our job— to make sure that they get our “vision” right, and it performs as you intended. It can be a thankless job, so show these guys some love.
Get in the feedback loop in short sprints versus long detailed reviews.
The best projects I have been a part of had the design team reviewing small bits that take 20-30 minutes, versus, long detailed reviews. Going back to our “quick wins” this is a way to create quick wins, so when there is a snag, you all have brain space to dedicate to it.
Be very careful of major changes!
There is always the last minute idea that gets added to the pot that you didn’t think of in the design phase. It ALWAYS happens. When this happens (not if), be very aware of the impact of this. Minor changes are to be expected, but major changes often busts a team’s morale at a critical point in the project. Tread lightly. Product owners are notorious for adding things at the last minute, often unaware to the SNAFU that it adds to morale of development, design and production.
My philosophy is unless it is a major usability issue, save last minute ideas for the next sprint. Complete what you have, test it, verify your hypothesis, and get feedback. It can also lead to a “just get it done” mentality which gets it done half-a**ed. If you are going to add some major functionality or process change at the last minute, tread lightly and think through your decision. Is it mission critical at this point? Is it a nice to have? What are the ramifications of adding this in the grand scheme of the product. How will it affect morale?
If you you decide to move forward with a major change, drinks should be on the product owner— for real! If you are a Product owner and you decide on a major pivot, treat your production team very nice and be very appreciative of the work they do. It will help boost the energy and morale.
Whether or not you are a leader on a project, or a team member, you need to do what you can to help a project move along, and keep everybody engaged and energized over the course of a project. Nothing will ruin a project worse than a lack of enthusiasm. At the end of the day, every project is a team effort, and we owe it to our team to maintain energy and enthusiasm. Even the most engaging projects can be draining if you do not take some precautions along the way to maintain energy. It takes some planning and effort, but in the long run, the projects that keep energy throughout are the one’s we do our best work on, and the one’s we look back on with fond memories of.