Best Practices en Engagement Strategy: a unified vision of success <span class="title">Engagement Strategy: a unified vision of success</span> <span class="uid"><a title="View user profile." href="/team/rick-cecil">Rick Cecil</a></span> <span class="created">Thu, 02/12/2015 - 22:00</span> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <div class="field-image"> <img src="/sites/default/files/styles/large/public/blog/engagement-strategy.jpg?itok=omdjPx8i" width="480" height="249" alt="Chess pieces" /> </div> <div class="body"><p><em>Facebook. Twitter. Instagram. Pinterest. Mailing lists. Website. Blog. Comments. Calendar. Forums. Mobile. Web. Apps. Tablets. Phones. Content Strategy. Marketing Strategy. Experience Strategy. Brand Strategy. Web Analytics. Contextual Inquiry. Market research. Usability Testing. Interaction Design. Information Architecture. UI Design. SEO. Landing Page Design. User Experience. Creative Design...</em></p> <p>And the list goes on.</p> <p>There are a lot of different ways to look at how you want your users to interact with your brand online. Each with its own perspective and ideas on how you can spend your limited budget.</p> <p>How do you choose the most appropriate tools for the task at hand? Maybe the more important question: do you fully understand the problem you are trying to solve?</p> <p>At Bluespark, we’ve been taking a long hard look at how all these dots (social, web, mobile, etc.) connect and we realized something: it’s not enough to connect the different strategy and design dots. We need to provide a unified, strategic direction that each of these disciplines can use to orchestrate and focus their efforts.</p> <p>Not only that, but this vision needs to be clear and needs to evolve in the face of a rapidly changing world.</p> <p>No easy task.</p> <h2><strong>The old way, not-the-same-as-the-new way.</strong></h2> <p>You might think that a good Discovery process can answer solve this problem. There are a few issues that arise when you rely on Discovery for this, though.</p> <p>First, each project has a separate Discovery process. So, if you have one project meant to improve your content strategy, another for your website, and yet another for your social media strategy, you’ll have three different Discovery meetings. Of course, all of these Discovery meetings are important — especially if you’re working with different vendors for each project. But, Discovery should be focused on clearly defining your expected project outcomes (meaning Key Results, which we’ll talk about below) rather than defining high level vision.</p> <p>Which brings us to the second issue: Discovery sessions often mix in strategic definition when they should really be focused on defining tactics around a previously defined strategy. Most of the clients I have worked with (from AT&amp;T  to local non-profits) rarely have a clearly defined strategy.</p> <p>This is a problem. Not only because you can easily end up with your social media plans at odds with your web plans at odds with your content strategy. At the very least, there may need to be a lot of re-work because of misunderstanding and miscommunications as each project moves from idea to code.</p> <h2><strong>The new way, better-than-the-old way.</strong></h2> <p>Our approach to this problem has evolved over the past year into what we’re calling Engagement Strategy.</p> <p>There are several parts to <em>Engagement Strategy</em>, but at its core, it’s a high level look at your brand, channels, and audience—and how they interact with each other. To create our Engagement Strategy process, we’ve pieced together techniques and methodologies from some of the smartest minds around the world along with our own experience to create something that is core to the business process, measurable, and successful.</p> <h2><strong>Understanding...</strong></h2> <p>As with any great process, <em>Engagement Strategy</em> starts with understanding. You may, in fact, have many of these pieces in place today. What we want to do, though, is pull these things together so that we have a solid foundation of understanding to build our models and lay our plans.</p> <h3><strong>...your brand</strong></h3> <p>If you want to set a clear direction for your entire web presence, we need to first understand your organization.</p> <p>The first thing we look at, with any Engagement Strategy, is your mission: What are you setting out to accomplish? We’re looking at a variety of things in your business including stakeholders, revenue centers, and, most importantly, we’re looking for your business mantra. That one succinct statement that explains why your organization exists can provide clear direction for everything the business does. Don’t worry, if you don’t have one, we’ll work with you to define it.</p> <p>Read more: If you’re not familiar with Mantras, we suggest you <a href="" target="_blank">watch this quick video</a> from Guy Kawasaki explaining the concept.</p> <p>One concept we want to experiment with, next time around, is actually creating a persona for the organization. Something that describes the personality of the organization—both how it exists today and how you’d like it to exist in the future.</p> <h3><strong>...your platform</strong></h3> <p>Your web platform consists of all the different ways you engage your audience online. For our purposes, we focus on your Web platform, but a broader scope could also include sales, customer service, and any other way physical way that you connect.</p> <p>Your web platform can consist of any combination of social media (Facebook, Twitter, Instagram, Pinterest), websites (marketing site, landing pages, blog, comments, calendar, and forums), and across devices (mobile, web, apps, tablets).</p> <p>It can be a lot. But it’s helpful to explore how you use each channel and, conversely, how your audience uses the channels to engage with your brand.</p> <h3><strong>...your audience</strong></h3> <p>Audience analysis examines your existing customer research (both demographic and ethnographic) and compares that to the understanding your key stakeholders hold. From these, we create a set of profiles and personae to represent these users. In addition to document the motivations, goals, and needs for each audience type, we also want to look at how each profile engages with your brand across the different channels we’ve identified.</p> <h2><strong>Get Clarity: Successful Engagement</strong></h2> <p>Once we have clarity on your business, audience, and platform, we can start to do some interesting modeling. This is where we start to get real clarity — clarity that we will use to set our Objectives that our different disciplines and organizations will use to drive their focus.</p> <h3><strong>Relationship Model</strong></h3> <p>If you have multiple audiences (and you probably do), we want to model how the different audiences relate to each other. In some cases, there may be a progression from one audience-type to another. In other cases, the different audiences may exist completely separate from each other.</p> <p>The Relationship Model will reveal any connections between the audiences that we may have missed — particularly around which audience may have influence over other audiences.</p> <h3><strong>Customer Journey Map</strong></h3> <p>The Customer Journey map looks at the different interactions your customers have with your organization along different services or sales and marketing funnels. Typically, when we do these engagements, we focus on the top one or two customer types.</p> <h3><strong>Engagement Model</strong></h3> <p>After we have the Customer Journey, we evolve that into an Engagement Model.</p> <p>Your Engagement Model takes the different customer touchpoints and creates an engagement funnel that shows how that customer will progressively increase their engagement with your brand across the different channels of your web platform.</p> <p>We also identify Key Performance Indicators (KPIs) for each stage of the model. These KPIs indicates the health of that stage. If it’s down, it needs work. If it’s up, you keep doing what you’re doing.</p> <h2><strong>Get Focused: Objectives and Key Results</strong></h2> <p>What do we have so far?</p> <p>We have an understanding of your audience, business, and platform. We also have a model for audience engagement across your different channels.</p> <p>Now, we need to turn these insights into focus! This last step of the Engagement Strategy is to define Objectives for any projects and allow your project teams to define Key Results for your objectives.</p> <p>Objectives are high level, ambitious goals. They are not measurable. But they do align everyone’s efforts around a single direction. Objectives can (and, really, should) be informed by all the work we’ve conducted to date — from the analysis of your business, audience, and platform to the clarification we’ve gained from our modeling.</p> <p>You can set Objectives at a variety of levels within your organization. In other words, these do not need to come from the highest levels of your organization to be effective, but the higher up the chain they go, the more effective they will be.</p> <p>Once your Objectives are defined, your project teams (Content Strategy, Marketing, Experience Strategy, development, etc.) will be responsible for setting measurable Key Results. Key Results are small, measurable improvements. They should be difficult to achieve, but not impossible. If you ever hit 100% of the KR, then you’re not setting your target high enough. By some estimates, the sweet spot of your Key Result should be 70-80% of your target.</p> <p>Learn more: Intel pioneered Objectives and Key Results. Christina Wodtke has a <a href="">great description</a> of OKRs on her blog. Rick Klau <a href="">presented the OKR concept</a> to Google Startup Labs.</p> <h2><strong>The End is the Beginning</strong></h2> <p>The goal of this process is not to deliver a set of documents that you use once and throw away. In fact, the documentation delivered at the end is incomplete. It’s part of a whole that needs to be evolved and expanded over time. New objectives set. New audiences defined. Audience definitions refined as you learn more about them.</p> <p>Ideally, you this process gives you clarity of your audience, business, and platform, which you use every quarter (or so) to define objectives and key results, which, in turn, leads to clarity around which features, content, and experiences your teams should focus.</p> </div> <div class="field-tags"> <div>Filed Under</div> <div> <div><a href="/blog/tags/best-practices" hreflang="en">Best Practices</a></div> <div><a href="/blog/tags/design" hreflang="en">Design</a></div> <div><a href="/blog/tags/information-architecture" hreflang="en">Information Architecture</a></div> </div> </div> <section class="comment"> <div class="comment__list"> </div> <div class="comment__form"> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=456&amp;2=comment&amp;3=comment" token="a1YLEZa7PEKkkXFdcs3wMPr7CkxcB3vaq3g_ALFZBiU"></drupal-render-placeholder> </div> </section> <div class="field-expertise"> <div>Area</div> <div> <div><a href="/expertise/strategy" hreflang="en">Strategy</a></div> </div> </div> <div class="field-cta"> <div>CTA</div> <div> <div><a href="/block/17" hreflang="en">Partner Next Project</a></div> </div> </div> </div> </div> Thu, 12 Feb 2015 21:00:27 +0000 Rick Cecil 456 at A Beautiful Friendship: How Bluespark and TripAdvisor put relationship best practices to work, and how you can, too. <span class="title">A Beautiful Friendship: How Bluespark and TripAdvisor put relationship best practices to work, and how you can, too.</span> <span class="uid"><a title="View user profile." href="/team/quinn-dalton">Quinn Dalton</a></span> <span class="created">Thu, 05/01/2014 - 11:08</span> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <div class="field-image"> <img src="/sites/default/files/styles/large/public/blog/hero-obermeyer.jpg?itok=OTqZWSJc" width="480" height="345" alt="" /> </div> <div class="body"><img alt="tripadvisor logo" src="/sites/default/files/resources/ta_logo.png" /><p>If you’re a consulting company, as Bluespark is--our international team specializes in building beautiful web sites using the Drupal CMS, with an emphasis on powerful user experience and design--you know that excellent work is necessary but not sufficient to achieve a great (or even a good) relationship with your client.</p> <p>Ultimately, no matter how hard you work, it’s the relationship that will decide whether the project is a success -- or, more to the point, whether your client believes it was a success.</p> <p>You’re probably already an expert at listening not just to what clients say, but what they don’t say. You’re an accomplished reader of subtext. You work to build trust because if your client isn’t comfortable, you know it’s going to be a lot harder to sell them on your ideas.</p> <p>You also know that a great relationship doesn’t happen just by chance, and it’s not just because “they don’t question our bills and they pay on time” (though of course that’s something any service company wants).</p> <p>No, a great relationship is the result of specific acts. And as you might imagine, it’s a two-way street. When it happens, it’s worth looking at what you and your client have done to make it happen.</p> <p>So we have some ideas for you, whether you’re the client or the vendor.</p> <p><strong>FOR VENDORS</strong></p> <p><strong>Become an extension of your client’s team.</strong></p> <p>People like to talk about this, but it doesn’t happen much. Why? Because vendors have strong ideas about what’s best for their clients. They have experience not only in their client’s industry but most likely in others as well, and they’re more up to date on the best technologies to achieve client goals. They know more (they assume) and so they’re prone to pressing the point on their ideas rather than finding a way to meet clients where they are.</p> <p>When<strong> TripAdvisor, the world’s largest travel site</strong>, approached Bluespark looking to improve their existing Wordpress solution for communications with business owners, we felt sure that a Drupal-based solution would best achieve their aims. This was after all a marketing platform with heavy content management requirements reaching a global audience (and they wanted to increase the number of languages supported from 7 to 20).</p> <p>We weren’t just thinking Drupal because that’s our core platform; we truly believed from the start that it was the best way to go. Nevertheless, we engaged in a comprehensive evaluation with TripAdvisor, providing any information they asked for, and we were willing to talk about Drupal’s limitations in the context of their goals, not just its advantages.</p> <p>After this process, we jointly agreed that moving to Drupal would provide us with a more flexible framework to meet current and future needs. This wasn’t just performing listening exercises to stroke the client. This was serious work, and in the process we got to know their team, their various concerns, and the way they liked to communicate.</p> <p>Once we got started on defining the actual project, we were already a tight knit team. We’d earned their trust by being honest. We continued to offer them all the resources they needed.</p> <p><strong>Be flexible on who does what. </strong></p> <p>TripAdvisor’s technical team handles implementations concerning the existing TripAdvisor stack, and they also handled the visual design. We brought to the table our UX expertise and the actual Drupal development. We constantly looked for ways to fit what we were doing to their needs.</p> <p><strong>Be responsive.</strong></p> <p>This may seem to be a given, but it’s not. One of the most common questions we field when talking with prospective clients, especially ones that have been burned by bad vendor relationships in the past, is, “How fast is your response time?”</p> <p>Bluespark is an international, distributed team. This presented some challenge in terms of coordinating the regular progress meetings (at least weekly, sometimes more), but it also gave us an advantage--quite simply, we covered more of the clock. Team members in Europe had a head start on the US business day, which came in handy where updates were concerned.</p> <p><strong>Make your process transparent.</strong></p> <p>During the project lifecycle, some clients want more of a hands-on role than others. TripAdvisor, with its talented technical and design teams, had the wherewithal and the desire to be deeply involved in everything we worked on together.</p> <p>So every step of the way, we figured out together how to do the work. We made no assumptions. We  didn’t try to impose our process on them, but we were always willing to talk about how we work and what to expect.</p> <p>With a project of this scale, even when every player on the team is extremely skilled, coordination and communication is what will ultimately determine success.</p> <p><strong>FOR CLIENTS</strong></p> <p><strong>Demand the same level of organization from your own team that you expect from your vendor.</strong></p> <p>Let’s face it, TripAdvisor didn’t get to be the world’s largest travel site by hiring slackers. Their team is at the top of their game. They communicate expectations really well. They are always focused on keeping things on track. They are always, always prepared for meetings. There’s no drama and no one who has to be coddled.</p> <p>In short, they demand the best--not just from us, but from themselves<strong>.</strong></p> <p><strong>Know</strong> <strong>who the product owner is</strong>.</p> <p>Do you know what can do the worst to a relationship--and a project? Lack of clarity with respect to who the ultimate decision maker is. Who gets to break the tie? Who bears final responsibility?</p> <p>TripAdvisor always knows who this person is. After the TripAdvisor designers sign off on the visuals, we have someone who is clearly in charge to take the project from there. They are empowered to make decisions, or they are able to quickly come back to us with an answer.</p> <p><strong>Opt for a smaller core team.</strong></p> <p>TripAdvisor is a big company, and the work we’re doing with them reaches a global audience. But the total number of their people with whom we interact on a regular basis is three.</p> <p>Aside from the designers, there are six or seven others with particular knowledge or expertise that will cycle in and out depending on current project needs.</p> <p>On our end, it’s the same number--our Chief Technology Officer, Technical Director, and a Senior Developer. Other members of our team are brought in to handle specific pieces of work as needed.</p> <p>So with two international companies (TripAdvisor being a bit bigger than we are, perhaps!) there is a core group of six people making the decisions and performing the work that reaches millions of people globally.</p> <p><strong>Conclusion</strong></p> <p>All this may come off as a love letter of sorts, and we’re OK with that. We love our work, and we love working with TripAdvisor, as well as all our other great clients (expect more love letters in the future).</p> <p>Our hope is that you can put these ideas to work in your own client or vendor relationships.</p> <p>Great relationships reinforce what’s best in you and support you in stretching your best even further. TripAdvisor has done that for us, and we like to think we’ve done the same for them.</p> </div> <div class="field-tags"> <div>Filed Under</div> <div> <div><a href="/blog/tags/drupal-planet" hreflang="en">Drupal Planet</a></div> <div><a href="/blog/tags/best-practices" hreflang="en">Best Practices</a></div> <div><a href="/blog/tags/project-management" hreflang="en">Project Management</a></div> </div> </div> <ul class="links inline"><li class="comment-add"><a href="/blog/beautiful-friendship-how-bluespark-and-tripadvisor-put-relationship-best-practices-work-and#comment-form" title="Share your thoughts and opinions." hreflang="en">Add new comment</a></li></ul><section class="comment"> <h2 class="comment__list__title">1 Comment</h2> <div class="comment__list"> <a id="comment-1925"></a> <article data-comment-user-id="0" class="js-comment comment__item"> <mark class="hidden" data-comment-timestamp="1398950921"></mark> <footer> <div class="comment__avatar"> <div class="user-picture"> <img srcset="/sites/default/files/styles/author/public/pictures/avatar.jpg?itok=2koKtKoC 45w, /sites/default/files/styles/author_2x/public/pictures/avatar.jpg?itok=vGSgtsSh 90w" sizes="45px" src="/sites/default/files/styles/author/public/pictures/avatar.jpg?itok=2koKtKoC" alt="" /> </div> </div> <p class="comment__info"> <span>rszrama (not verified)</span> - <span class="comment__info--date">Thu, May 1, 2014 at 1:28 pm</span> <span class="comment__link--permalink"> <a href="/comment/1925#comment-1925" hreflang="en">Permalink</a> </span> </p> </footer> <div> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <drupal-render-placeholder callback="comment.lazy_builders:renderLinks" arguments="0=1925&amp;1=default&amp;2=en&amp;3=" token="2WdYC5TjVlZmUMsoAA_-7sd-YcYY-12KUtxoiT95MXk"></drupal-render-placeholder> </div> </div> </div> </article> </div> <div class="comment__form"> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=324&amp;2=comment&amp;3=comment" token="QK_L2fZ7hjJxQ8BRELHskO1ggAyP_oMRGgraPwb_pyA"></drupal-render-placeholder> </div> </section> <div class="field-expertise"> <div>Area</div> <div> <div><a href="/expertise/development" hreflang="en">Development</a></div> </div> </div> <div class="field-resources"> <div>Resources</div> <div> <div><span class="file file--mime-image-png file--image"><a href="" type="image/png; length=35088">ta_logo.png</a></span> </div> </div> </div> <div class="field-cta"> <div>CTA</div> <div> <div><a href="/block/17" hreflang="en">Partner Next Project</a></div> </div> </div> </div> </div> Thu, 01 May 2014 09:08:20 +0000 Quinn Dalton 324 at How Changing our Estimation Process Took our Project Endgame from WTF? to FTW! <span class="title">How Changing our Estimation Process Took our Project Endgame from WTF? to FTW!</span> <span class="uid"><a title="View user profile." href="/team/ashleigh-thevenet">Ashleigh Thevenet</a></span> <span class="created">Wed, 04/16/2014 - 22:19</span> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <div class="field-image"> <img src="/sites/default/files/styles/large/public/blog/changing-our-estimation%20%282%29_0.jpg?itok=uW3GhfI8" width="480" height="249" alt="Closeup of person writing, surrounded by computer and coffee mug" /> </div> <div class="body"><p>Recently I had the pleasure of presenting a session at Midcamp Chicago entitled “How Changing our Estimation Process Took our Project Endgame from WTF? to FTW!”.  Perhaps you weren’t able to attend Midcamp, or maybe you were in attendance but decided to go to a different session (why would you do that?!), whatever the reason, here’s what you missed:</p> <p>Wouldn’t it be nice if the majority of clients didn’t need to worry about the overall project budget and would just let your team work their development magic and build whatever they need? It would be great, but it certainly isn’t realistic. The reality is that most clients are working with a budget for their project and therefore you are too. This often translates to fixed bid projects that are awarded after an RFP process brings in proposals from a variety of potential vendors.  </p> <p>When you receive an RFP, it frequently includes a laundry list of features that the client would like to have within the allotted budget.  So, you review the objectives in the RFP, you meet with the client to discuss and ask any questions you may have, and then convene internally to develop a game plan as to how you will tackle the project.  You write up your recommendations in your proposal and of course, you include a budget. But at this point, what is the budget really besides a total and complete wild guess? It is a beautiful budget, and you’ve worked very hard at putting it together for your potential client, but this early in the project it is based entirely on assumptions.  </p> <p>What the client wants to see here is that you can meet their stated objectives within their defined budget, so they’re looking at the grand total and not always at the budget details.  So this means that the estimate needs to be updated as your project evolves.</p> <p>We didn’t always revise the estimate as a project evolved, and we learned the hard way that not doing so gives clients unrealistic expectations of what they will be getting within their fixed budget.  The problem is that there is a rather chasmic difference between a bullet list of features in an RFP and complete specifications with interaction requirements and wireframes.</p> <p>The same feature listed quickly in an RFP can require anywhere from 10-100 hours to build, depending on how it is spec’d out.  When the client writes their RFP and when you prepare your initial budget, the actual specifications for the features are unknown.  The actual scope of the features only becomes clear once you have conducted a discovery process and put together wireframes and interaction requirements.  We realized that in order to better manage client expectations and project budget on fixed bids, we needed to do two things:</p> <ul><li>Integrate two new steps in our process in the form of estimate revisions at the end of the discovery and design phase as project milestones.</li> <li>Be transparent with our clients, telling them early and often that their budget will only cover so many features and it is their responsibility to prioritize and determine which features should be part of the Minimal Viable Product (or the basic, necessary features your client needs to launch their site). </li> </ul><p>Our redefined process involves several steps:</p> <h2>Kick off Meeting </h2> <p>It’s important to begin managing client expectations early on. These meetings are typically pretty informal discussions where we ask the client to describe their objectives in their own words.  We then review our process, the different project milestones, the budget review and make sure the client is aware that decisions made in terms of prioritization in the discovery phase will effect where their budget is spent when it comes time to build.</p> <h2>UX Sketches</h2> <p>After the kick off meeting, our UX designer meets with the client to get a handle on their priorities and vision for the site. After this meeting, he works to develop some preliminary sketches and we present these to the client.  The sketches are then refined based on client feedback in a rapid iterative design process.  We try to iterate quickly on the sketches and get multiple rounds of feedback until we come to a point where the client is satisfied with what we’ve put on paper.  With approved sketches in hand, we are ready for our next milestone.  </p> <h2>Early Technical Planning </h2> <p>Our Early Tech Planning meetings typically involve the tech lead, UX designer and PM.  The UX designer reviews the sketches with the tech lead and the PM adds tickets to our project management system that cover the big pieces of work to be done.  The Tech lead determines a rough estimate for each ticket, at this point the features aren’t defined enough to truly decide how any specific feature will built.  The end goal is to determine an overall budget with a 40% accuracy rate. The idea here is to see where we stand in terms of development hours. We want to identify any key bits of functionality or features that may be taking a disproportionate amount of budget and see if that aligns with client priorities.  If not, we still have time to modify the sketches and upcoming wires accordingly and we haven’t lost any dev time building the features so there is no harm done.</p> <h2>Wireframes </h2> <p>After our Early Tech Planning client review, we continue refining the UX sketches with the client until we come to a point where we have complete and approved wireframes and interaction requirements.  This is really the key to being able to complete the next step in our process - the Final Tech Planning.</p> <h2>Final Technical Planning</h2> <p>The Final Tech Planning is a complete review of the wires and interaction requirements in which we determine the information architecture, take implementation notes and estimate all the features with the goal of achieving a 10% accuracy rate.  We plan several meetings over the course of a week, each meeting is about 2 hours.  </p> <p>The total number of meetings needed depends on the project complexity.  We include the tech lead, two developers, a themer, the UX designer and the PM.  We start with the list of issues that we added in our Early Tech Planning, we select a site section and the UX designer reviews the wireframes and interaction requirements with the team. We do not share the previous estimates with the dev team. Lots of discussion ensues as the developers decide upon how they will build what they see in the wires.</p> <p>These decisions are written down in the form of implementation notes to be added to the individual tickets after the meetings.  As the developers define the best way to build what’s in front of them, they come to a point where they are ready to estimate the work at hand.  Each developer gives their number and we generally take the high end of average and this estimate is added to the ticket by the PM.</p> <p>At the end of these long, intense, meetings, we tally up the estimates and see where we stand.  The PM then prepares a full feature list and hours breakdown that we present to the client.  If the total estimate is above the available budget, we also prepare our recommendations of  features that could potentially be de-scoped without sacrificing the project integrity.</p> <p>There are several options that can come out of a situation in which the Final Tech Planning estimate is higher than the available hours:</p> <ol><li>We de-scope certain features/issues and save them for a later project phase: sometimes when confronted with budget restrictions a client will accept to wait to build certain features until they have further funding. </li> <li>Perhaps the client has an internal dev team that can take on some of the dev work and collaborate with our team: in this situation the development work becomes a co-build.  We determine which team will work on which issues and have weekly dev scrums to follow progress.  This allows the client to get more functionality without having to pay for additional development hours from our team. </li> <li>Perhaps there is additional budget to cover the hours: if the client doesn’t have an internal team to take on some of the work and they can not push any of the features back to a later phase of work, then perhaps they can find additional funding within their organization to cover the projected overage.</li> </ol><p>So, we share our recommendations of features that can potentially be de-scoped and give them other options of how the potential budget overage can be dealt with, this allows them to make the final decision.  The project scope and budget is in their hands. The client then takes some time to review and think through their options and feature list and then come back to us with a game plan.         </p> <h2>From Building to Wrapping the Project</h2> <p>Once the client has approved the feature list and everyone is in agreement as to the final scope, you can begin building.  This part of the project should go quite smoothly since you have done so much tech planning work already.  The dev team has everything they need to get started in the tickets, and the tech lead and PM can easily plan sprints since the estimates and dependencies are all laid out.  As you wrap the project you should see that an overall estimate accuracy - +/-10% holds true.  </p> <p>With this process and the integrated client expectation readjustments, you should have a happy client who got what they wanted, within their budget and was informed throughout the process.  You have consulted with your client multiple times throughout the project, getting them to decide where they want their budget to be spent.  In our experience, clients truly appreciate this empowerment, and this transparency.  It makes them active project members, they haven’t just given us some money and a list of things and said build this, they are making decisions and molding the project as it progresses.  </p> <p><br /><br />  </p> </div> <div class="field-tags"> <div>Filed Under</div> <div> <div><a href="/blog/tags/midcamp" hreflang="en">Midcamp</a></div> <div><a href="/blog/tags/project-management" hreflang="en">Project Management</a></div> <div><a href="/blog/tags/best-practices" hreflang="en">Best Practices</a></div> <div><a href="/blog/tags/drupal-planet" hreflang="en">Drupal Planet</a></div> </div> </div> <ul class="links inline"><li class="comment-add"><a href="/blog/how-changing-our-estimation-process-took-our-project-endgame-wtf-ftw#comment-form" title="Share your thoughts and opinions." hreflang="en">Add new comment</a></li></ul><section class="comment"> <h2 class="comment__list__title">1 Comment</h2> <div class="comment__list"> <a id="comment-1922"></a> <article data-comment-user-id="0" class="js-comment comment__item"> <mark class="hidden" data-comment-timestamp="1398099031"></mark> <footer> <div class="comment__avatar"> <div class="user-picture"> <img srcset="/sites/default/files/styles/author/public/pictures/avatar.jpg?itok=2koKtKoC 45w, /sites/default/files/styles/author_2x/public/pictures/avatar.jpg?itok=vGSgtsSh 90w" sizes="45px" src="/sites/default/files/styles/author/public/pictures/avatar.jpg?itok=2koKtKoC" alt="" /> </div> </div> <p class="comment__info"> <a rel="nofollow" href="">Aimee (not verified)</a> - <span class="comment__info--date">Mon, Apr 21, 2014 at 4:50 pm</span> <span class="comment__link--permalink"> <a href="/comment/1922#comment-1922" hreflang="en">Permalink</a> </span> </p> </footer> <div> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <drupal-render-placeholder callback="comment.lazy_builders:renderLinks" arguments="0=1922&amp;1=default&amp;2=en&amp;3=" token="L1CvLNRwitR_EWNvocsUwxkNJNMGM3-CfX2hEYo4PKU"></drupal-render-placeholder> </div> </div> </div> </article> </div> <div class="comment__form"> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=322&amp;2=comment&amp;3=comment" token="12VZ40RyB_xe3AiN8dDlzdPCpvMh65VNJAe1Mjlc3nQ"></drupal-render-placeholder> </div> </section> <div class="field-expertise"> <div>Area</div> <div> <div><a href="/expertise/user-experience-ux" hreflang="en">User Experience (UX)</a></div> </div> </div> <div class="field-cta"> <div>CTA</div> <div> <div><a href="/block/17" hreflang="en">Partner Next Project</a></div> </div> </div> </div> </div> Wed, 16 Apr 2014 20:19:21 +0000 Ashleigh Thevenet 322 at Goldberg Machine <span class="title">Goldberg Machine</span> <span class="uid"><a title="View user profile." href="/team/michael-tucker">Michael Tucker</a></span> <span class="created">Wed, 08/15/2012 - 15:06</span> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <div class="field-image"> <img src="/sites/default/files/styles/large/public/blog/hero-obermeyer.jpg?itok=OTqZWSJc" width="480" height="345" alt="" /> </div> <div class="body"><img src="" width="300px" style="float:left; padding:0px 6px 0px 0px" />When I was a kid, we had a game called Mouse Trap that was based on the <a href="" target="new">Rube Goldberg machine</a> concept. The game pieces resembled common household items like a bathtub, shoe, plumbing pipes, a ladder, etc. You took turns building a trap, piece by haphazard piece. If you were successful, you’d have a complex but fragile working trap to capture the other players’ mouse. But while you built, the constant danger was that you might touch one piece or another and ruin the trap: game over. An interactive agency with open source development expertise, Bluespark is often asked by prospects or clients to assume developmental control over an existing site. With increasingly alarming frequency, we often find that the site is poorly conceived and inexpertly built. Often what we find is the web equivalent of a Goldberg machine. Here is a sad fact in this business: there are plenty of people, often quite professional in other fields — like designers or agencies — who learn a little bit about code, throw together a few experimental sites and then hang out a shingle as a 'web company'. Frankly (and this might sting a little) these people have no experience developing complex software, which is what a well-conceived Drupal site can be. There are some telltale signs. If there’s no staging server, no code repository, and no launch procedure, we have proof enough that the previous team did not have a familiarity with professional code development standards. Of course, Bluespark has the expertise to set up an environment and sane code management procedures, and can begin hacking away at a site like this and eventually get everything untangled and/or rebuilt in a way that makes sense. But there are huge risks. Suppose you win a big client who needs a rescue. Congratulations. You're the web team now, and you're responsible for a Goldberg machine you did not create. The previous guys somehow managed to get the site to a stable point - likely way over budget and way off schedule. They’re out. You’re in. You’re asked to improve the site. You can chase down the errors and fix them, but always at the risk of causing another problem somewhere else. Surprise! You've touched the wrong component, and the site has blown up. You bravely soldier on, trying to find a way to get it all back to stability. In the meantime, all eyes are on you because, "It was working until you touched it,” and “What are these delays?” and “This is costing us money!" You didn’t build it, but you’re catching the heat. No one will remember who created this mess. Very quickly, the client’s perception of the "Web team" becomes synonymous with "web site" and inherits all of its problems. If the web site sucks, then the web team sucks. That's the nature of the beast. Trust me, it is not good for an expert to be in this position. A Goldberg system is only marginally operational at any point in time. So when everything works, it is only for a short period. The moment you start tinkering and improving you're instantly back to a zero sum game. You can't win because you can't predict what the overall effect of the tinkering will be. With a site like this you are always going to be in a state of either flat-out emergency or semi-emergency, simply because you always want to improve it. The reality of working on a delicate system causes unpredictable issues, which become emergencies. The only way to stop the cycle is to get it to where it semi-works and *don't touch it* and then build a non-goldberg machine with the same functionality on another server. But because the site mostly works, the temptation, particularly for your non-technical client, is to keep futzing with it and trying to improve it. But it never gets there. As a consequence, your client is in a constant state of panic and continuously throwing money down the drain. Here’s the only solution. As soon as you identify your Goldberg, blow the whistle. As a service provider, you might think you can just keep plugging away at it. You could, and eventually you might turn the site around. But often the best thing for you and for your client is to stop, recognize the situation, and rebuild. Even though the financial hit could be significant and immediate, ultimately the bottom line is that a stable, extensible, scalable site is cheaper to run over the long haul. If you don’t, you perpetuate an untenable situation for you both. The longer you wait, the more it will feel to your client like you’re abandoning them and giving up. So show your expertise, show your professionalism and if needed, be willing to walk away. Let someone else trap that mouse.</div> <div class="field-tags"> <div>Filed Under</div> <div> <div><a href="/blog/tags/drupal-planet" hreflang="en">Drupal Planet</a></div> <div><a href="/blog/tags/drupal" hreflang="en">Drupal</a></div> <div><a href="/blog/tags/best-practices" hreflang="en">Best Practices</a></div> </div> </div> <section class="comment"> <div class="comment__list"> </div> <div class="comment__form"> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=202&amp;2=comment&amp;3=comment" token="k2TOXVPv8Zz-eq-ZQQCumVuKmNZep3DfKnF9bxaSDMQ"></drupal-render-placeholder> </div> </section> <div class="field-expertise"> <div>Area</div> <div> <div><a href="/expertise/development" hreflang="en">Development</a></div> </div> </div> <div class="field-resources"> <div>Resources</div> <div> <div><span class="file file--mime-image-jpeg file--image"><a href="" type="image/jpeg; length=42374">mtg.jpg</a></span> </div> </div> </div> <div class="field-cta"> <div>CTA</div> <div> <div><a href="/block/17" hreflang="en">Partner Next Project</a></div> </div> </div> </div> </div> Wed, 15 Aug 2012 13:06:46 +0000 Michael Tucker 202 at An Invocation for Beginnings <span class="title">An Invocation for Beginnings</span> <span class="uid"><a title="View user profile." href="/team/michael-tucker">Michael Tucker</a></span> <span class="created">Thu, 04/19/2012 - 00:23</span> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <div class="field-image"> <img src="/sites/default/files/styles/large/public/blog/hero-obermeyer.jpg?itok=OTqZWSJc" width="480" height="345" alt="" /> </div> <div class="body"><iframe width="425" height="246" src="" frameborder="0" allowfullscreen=""></iframe> Wow, pretty powerful stuff, Ze. Thanks for that. One that hit me: "Let me not be so vain to think that I'm a sole author of my victories and a victim of my defeats." And: "God let me enjoy this. Life isn't just a sequence of waiting for things to be done." Did something he said hit home? Why?</div> <div class="field-tags"> <div>Filed Under</div> <div> <div><a href="/blog/tags/best-practices" hreflang="en">Best Practices</a></div> </div> </div> <section class="comment"> <div class="comment__list"> </div> <div class="comment__form"> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=181&amp;2=comment&amp;3=comment" token="YOdrOSIe4aDiIBeTePOfVRw1_M_VKRZn0VLJclz6Ufs"></drupal-render-placeholder> </div> </section> <div class="field-expertise"> <div>Area</div> <div> <div><a href="/expertise/design" hreflang="en">Design</a></div> </div> </div> <div class="field-cta"> <div>CTA</div> <div> <div><a href="/block/17" hreflang="en">Partner Next Project</a></div> </div> </div> </div> </div> Wed, 18 Apr 2012 22:23:58 +0000 Michael Tucker 181 at Ask: What can you remove? <span class="title">Ask: What can you remove?</span> <span class="uid"><a title="View user profile." href="/team/rick-cecil">Rick Cecil</a></span> <span class="created">Wed, 04/18/2012 - 14:17</span> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <div class="field-image"> <img src="/sites/default/files/styles/large/public/blog/hero-obermeyer.jpg?itok=OTqZWSJc" width="480" height="345" alt="" /> </div> <div class="body">How often do you get stuck on a design problem? For me, it usually happens when we go from the concept of a thing to the first version of the wireframes. Yes, it made some sense to group these 10 things together, but from a design standpoint, we find that the page layout doesn’t work. Maybe there are too many things on the page. Or maybe there are too many DIFFERENT things on the page. Or, maybe, through the process of design, we realize that those things shouldn’t have been grouped together in the first place. Regardless of the reason, the best way out of these predicaments is not usually forward; it’s backward. Rather than continue to fight the design and try to squeeze everything into the available pixels, maybe you should ask: what can I remove to make this page simpler?</div> <div class="field-tags"> <div>Filed Under</div> <div> <div><a href="/blog/tags/design" hreflang="en">Design</a></div> <div><a href="/blog/tags/best-practices" hreflang="en">Best Practices</a></div> </div> </div> <section class="comment"> <div class="comment__list"> </div> <div class="comment__form"> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=179&amp;2=comment&amp;3=comment" token="E-aELUgNrv44tHVGOLERv7XUsGLhTEzr6UFQJASIXyQ"></drupal-render-placeholder> </div> </section> <div class="field-expertise"> <div>Area</div> <div> <div><a href="/expertise/user-experience-ux" hreflang="en">User Experience (UX)</a></div> </div> </div> <div class="field-cta"> <div>CTA</div> <div> <div><a href="/block/17" hreflang="en">Partner Next Project</a></div> </div> </div> </div> </div> Wed, 18 Apr 2012 12:17:35 +0000 Rick Cecil 179 at Bluespark's User Experience Design Principles <span class="title">Bluespark&#039;s User Experience Design Principles</span> <span class="uid"><a title="View user profile." href="/team/rick-cecil">Rick Cecil</a></span> <span class="created">Thu, 04/12/2012 - 19:01</span> <div class="layout layout--onecol"> <div class="layout__region layout__region--content"> <div class="field-image"> <img src="/sites/default/files/styles/large/public/blog/hero-obermeyer.jpg?itok=OTqZWSJc" width="480" height="345" alt="" /> </div> <div class="body">The success of a project — any project — begins with the right mindset. Without the right understanding of the world around us, we are limited in what we can accomplish. But with the right mindset, we can accomplish great things. The key to Bluespark's success on project after project starts with the right mindset as embodied by a core set of design principles: a core set of values that we use to approach every project. <strong>Powerful goals create powerful results</strong> <img src="" border="0" alt="Photobucket" align="right" style="margin-bottom:5px;" />The underpinnings of a successful project begin before you even write the RFP: What are you trying to accomplish with the project? Presumably that’s what your RFP or Statement of Work is intended to answer, but many times, these things get lost in the nuts and bolts of the hundreds of details that you’re trying to capture in these documents. So the first thing we want to understand are the real motivators behind the project and how do these motivations translate into business and user goals. Many times, through the process of discovery, we uncover goals that the client wasn’t even aware they had. Other times, we identify conflicting goals — conflicts within departments or even conflicts in what the client is trying to accomplish and what is being asked for in the RFP. Which leads us to our second principle: Question assumptions. <strong>Question assumptions</strong> You make assumptions. We make assumptions. And we all end up making asses out of ourselves because we made so many damned assumptions. <img src="" border="0" alt="Photobucket" align="left" style="margin-right:15px; margin-bottom:10px;" />We do our best to not take anything for granted. If you specified something in the RFP, we want to know why it’s in there and how important to the project’s success it really is. We want to know what functionality we can trade out for other functionality or ideas that might help you better achieve your goals. Nothing is off-limits here. Not because we like torturing you, but because this process has proven to deliver results. If you ask for an apple and I give you an apple, but what you really wanted was an orange, it’s my fault for not pushing you—for not questioning your assumptions about what you’re looking for. It’s the same with functionality, too. Often times clients have very specific requirements around some functionality they want. If we were to deliver on the functionality, though, will you like what you see? Maybe you will, but it’s better to question why each bit of functionality has been requested and re-focus the feature-set on our real goal. Ultimately, by understanding and questioning the underlying assumptions — assumptions you might not even realize you’ve made — we can tackle the real problems the project is trying to solve. <strong>Talk to the User</strong> You have your goals — and the assumptions driving those goals, and maybe we’ve even created some compelling designs around your powerful goals, but how do we know that what you want to build will actually achieve your goals? We don't, not really. We are missing some key insights that we can only gain by talking to your users. Let me illustrate. <img src="" border="0" alt="Photobucket" align="right" style="margin-left:10px;" />Did you watch the move The Social Network? Remember the scene where Zuckerburg is getting pressured from his friend to launch the site, but Zuckerburg insists that it’s not ready? It’s not until he gets asked about a particular girl’s relationship status that he understands what the site is missing. He rushes home, adds some simple code: Relationship Status. And then voila! He’s ready to launch. Zuckerburg wouldn’t have made this breakthrough had he not been talking to someone from his potential audience. Of course, in the conversation where the insight happened, Zuckerburg wasn’t trying to test his new product — he was actually on his way to class when the other student interrupted him. But the idea remains solid: talking to your users or potential users is the best and only way to really understand how they want to interact with your website or web application and it’s a critical part of how we work. Don’t mistake me. We don’t call up random users and ask them: “How do you want to interact with this website?” It’s not your user's job to know this — it’s your job. But buried deep within the daily rhythms of their life lies the answer. We can use a range of techniques from contextual interviews to iterative usability testing to understand their real needs (versus how they describe the need), and often we combine these two techniques to great effect. <strong>Iterate</strong> Great websites and web applications do not emerge from our process fully formed. What we deliver is the core of a great idea that, if done right, will deliver some key business value. It’s a starting point that over the course of time, can be refined and sharpened into a powerful tool. <img src="" border="0" alt="Photobucket" align="left" style="margin-right:15px; margin-bottom:10px;" />What we’ve learned over the years is that websites are not fixed and user's needs change over time. Just because the project has ended does not mean that the product is finished. Just because we met your user's need, does not mean that their needs won’t change over time or that new needs won’t arise. No, what we give you is a building block, the start of something great. And with Drupal as your backend, you will have the technology to grow and adapt your web presence as your audience needs grow. And that brings us to our last principle: what we want to deliver is a product that is as simple as possible so that you don’t spend time building something only to find, after launch, that you only needed half of what you built. <strong>Start as simple as possible</strong> As people, we have a tendency to want to launch web products and their features in the most pristine, complete state possible. If we picture a gallery, we envision Flickr. If we envision a blog platform, we envision Blogger or Wordpress. Nevermind that these services started out very different than what they are today — and, very possibly, are meeting a different need than what you’re trying to accomplish with your web product. The culmination of everything we’ve talked about to this point leads us to this principle: Start as simple as possible. The first version of the gallery on your site might not be an exact clone of Flickr. And, really, that’s okay because you don’t want to be an exact clone of Flickr — otherwise, why aren’t your users just using Flickr? By starting with fewer features and focusing on outcomes, we give you room to learn from your users, to understand what they’re trying to accomplish. We also give you a chance to understand and explore how you want to interact with your customers, to see how you can build a truly unique user and brand experience for your users.</div> <div class="field-tags"> <div>Filed Under</div> <div> <div><a href="/blog/tags/drupal" hreflang="en">Drupal</a></div> <div><a href="/blog/tags/drupal-planet" hreflang="en">Drupal Planet</a></div> <div><a href="/blog/tags/best-practices" hreflang="en">Best Practices</a></div> </div> </div> <section class="comment"> <div class="comment__list"> </div> <div class="comment__form"> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=166&amp;2=comment&amp;3=comment" token="N3gUbsdJsFt91wsJ6tk_E1tXtM_1JNU1gSNCWWL3eTk"></drupal-render-placeholder> </div> </section> <div class="field-expertise"> <div>Area</div> <div> <div><a href="/expertise/user-experience-ux" hreflang="en">User Experience (UX)</a></div> </div> </div> <div class="field-cta"> <div>CTA</div> <div> <div><a href="/block/17" hreflang="en">Partner Next Project</a></div> </div> </div> </div> </div> Thu, 12 Apr 2012 17:01:20 +0000 Rick Cecil 166 at