Skip to content Skip to navigation

Zach Chandler's Blog Posts

a face for radio Posted by Zach Chandler on Thursday, July 23, 2015 - 8:00am

Service Design is an emerging practice area that can transform organizations, and create immense value. Stanford Web Services has already begun to introduce Service Design into the way that they develop services for the University. We should all think about more ways to put it into practice.

Design Thinking permeates the air we breathe at Stanford. Innovation is one of our most highly prized values, and creativity is everywhere around us. We have the d.school, and the GSB, STVP, Product Design, and rapid prototyping labs, and we staff members should make good use of that ambient vibrancy. Service Design offers a practical method of doing that.

But what is it? In a nutshell, Service Design is the application of Design Thinking to services, rather than products. It involves making work visible, collaboration and empathizing with stakeholders and service providers alike; and it leverages d.school style methods like prototyping, problem reframing, visualization, and feedback loops. Oh, and stickies. Lots, and lots of stickies. (For a more thorough explanation of what it is, listen to Birgit Mager.) Alternatively we can call this field Service Experience Design, or SXD.

At DrupalCon Los Angeles, our very own Megan Miller introduced Service Design to the Drupal community. I have learned a lot from Megan, and she’s a great storyteller. Megan is at the vanguard of SXD at Stanford (watch this space!), and my hope is that through our new Community of Practice, we can help others see how SXD can create breakthroughs. Look around you. Stanford is a small galaxy of autonomous nodes in a scale-free network of relationships and … services. All of it, all of it, is subject to design, and can be improved to have a greater impact on the mission of the University.

TIP: Megan has also compiled a page of Service Experience Design resources that includes definitions, terms, principles, and links.

Two years ago, Service Design was something that Megan and I were interested in, and had been meaning to learn more about. What made it real for us was attending the Service Experience conference in San Francisco in 2014. We went with a small cohort from University IT and Environmental Health and Safety. This year, we are returning to the SX Conf with an even greater number.

Service Experience Conference 2015

http://service-experience-conf.com/

Where: San Francisco

When: November 16-17

Who: You, hopefully

I think that this is an exciting time to be a part of the reinvention of our work, and just as David Kelley’s new focus is unleashing the creativity of others, I think that Service Design, and its particular vocabulary, mental models, and tools, is an exciting opportunity for all service providers to tap into their creativity, even if you don’t think you are creative … especially if you don’t think you’re creative. Think of SX Conf as innovation school, with highly practical methods you can bring back to your work. COME WITH US!

a face for radio Posted by Zach Chandler on Friday, December 12, 2014 - 6:55am

All forward-thinking technologies share one attribute: the original designers intentionally build in opportunities for future users to innovate. It requires humility and a belief in the creativity of others. This is true for buildings, computers, networks, and other tools.

As we design systems in Drupal, we should try to imagine how its flexibility can reward future sitebuilders, and allow for innovations that the principal designers cannot imagine themselves. This post is part of my answer to the perennial Why Drupal? question, but it’s also deeper than that, and gets at an inherent tension in web design that I’d like to examine carefully as SWS grows its product line. Drupal is a flexible tool-building-tool. Jumpstart is a purpose-built product. How do these attributes co-exist?

Room to Tinker

In October of 1990, having recently convinced CERN that a world wide web would be a good idea, Tim Berners-Lee sat down to write his first web client.  He had working software about a month later (!) due in no small part to the affordances of the computer he was using — a NeXT machine. As it turned out, the fact that Sir Tim was using a NeXT mattered. A lot.

“I still had to find a way to turn text into hypertext, though. This required being able to distinguish text that was a link from text that wasn’t. I delved into the files that defined the internal workings of the text editor, and happily found a spare thirty-two-bit piece of memory, which the developers of NeXT had graciously left open for tinkerers like me. I was able to use the spare space as a pointer from each span of text to the address for any hypertext link. With this, hypertext was easy.” [1]

In 1990, the emergence of the Web was not a foregone conclusion, in fact, this was a KM side project, a curiosity on which the CERN leadership gambled, and they gave Tim a couple of FTE for six months. That’s it. What if he had struggled with development because he had inflexible tools and had little to show when the six months was up? Would we even have the Web that we know today?

Learning from physical spaces

Leave room to evolve is an imperative that calls out from the landmark book Make Space, by Scott Doorley and Scott Witthoft.

“Allow the space and the people to continue to adapt and grow. Do less. leave some aspects of the space open-ended, even though your impulse might be to take care of every detail. … Open space provides a buffer for identifying, absorbing, and responding to unanticipated needs” [2]

Of course  most of the digital spaces that we build do not start with the same brand of high-flying creativity that bursts from the seams of the d.school (When was the last time your web project called for  9-foot grain thresher?). Nevertheless, there is a lot that we can learn from the ubercreative plaid-wearing set from Building 550. Sure, we iterate. We’re all agile and whatnot. Our projects have version numbers and roadmaps, and hell we even listen to real people (gasp!) and think about what they need before we make stuff for them. But what about identifying, absorbing, and responding to unanticipated needs? Evolving needs? Do we as web designers, have a line on how people inhabit the digital spaces we build, after the work is done? What are the hacks and workarounds that users employ to make our tools do what they actually need (c.f. desire paths), even the things that they didn’t know they needed when we asked them during discovery?

This is exactly the question that Stewart Brand explores in his book, How Buildings Learn: What Happens After They Are Built. Brand shows how people modify the places that they live and work, that the best buildings learn over time by the inhabitants hacking their own solutions to problems. Vernacular Architecture is the term for a transmitted popular culture, an eminently practical structural dialect that emerges in a given place, based on local needs.[3]  What distinguishes it from the high art of professional architects is that it follows the advice of the d.school above:

“Vernacular buildings evolve. As generations of new buildings imitate the best of mature buildings, they increase in sophistication while retaining simplicity.”

Can we build an Adaptive Architecture for the Web?

(Here I mean “adaptive” in Stewart Brand’s sense of creating room to tinker, not RWD.)

The good news is that Drupal is awesome at adaptation and scaffolding future growth. Stanford University is a mind-bendingly expansive enterprise, and we have chosen a tool that can expand as our needs on the web evolve.

For this reason Drupal is chosen over and over again by large, evolving organizations. It’s a domain modeling framework and a toolkit that can start simple, but expand to meet complexity, which is why it’s the tool of choice for many universities, the U.S. government, municipalities, non-profits, and large corporations alike.

Stanford Sites Jumpstart was conceived to harness the power of Drupal, but make it dead simple, even pleasant, to use. We pruned off the rough edges from the Drupal installation process, and gave our users a simplified UX that they could get started with from day one —without having to take a Drupal training class first!

This simplification approach has been wildly successful, and our users have validated this design philosophy. But have we let the pendulum swing too far toward simplicity? What if the needs of our users are complex? Let’s not lose sight of how we got here, how the great visionaries on whose shoulders we stand (like Steve Jobs, and Tim Berners-Lee) left us room to tinker, and to innovate. As we design today’s systems, let’s have a similar amount of faith in our future users.

“Let people do things.”
—Stuart Brand

Complications for Products

Though I am advocating for people to retain the freedom to tinker with the tools we create, this can be dangerous idea if we also expect these tools to also behave like products.

How does the imperative to design for future innovation jibe with platforms and products like Stanford Sites, Jumpstart, Open Atrium, Commons, DKAN, Open Aid, Open Outreach, etc. in which it might matter more that things Just Work™ ?

This is where the parallel with physical buildings breaks down: a builder of homes never hears from a client: “I’m sorry, I accidentally deleted all my walls, can you help me get them back?” If we follow Stewart Brand’s advice, and let people do things, they will inevitably break stuff. This is just going to happen, and is a natural step in the learning process of becoming a site owner, and eventually a Sitebuilder. As designers we have to have some tolerance for learning-by-breaking-things path, and resist the urge to make that impossible, since that choice ramifies toward taking away sitebuilding capacities altogether.

Challenge: the only way to enjoy the benefits of a distribution over time is to use it as intended, and not modify it’s fundamental aspects. Patching or modifying significantly takes you out of the upgrade path, and defeats the purpose of the distro as such. So how do we strike a balance?

I don’t really know the answer, but I do think that SWS is onto something with the Jumpstart product suite.  It’s a simplified user experience, but it’s still Drupal under the hood. We are consciously working on this problem of “leveling up”, which applies both to websites, and to users, as they learn and grow with their system. We work iteratively, we test, and we pay attention to the desire paths that our users convey in the way that they adapt what we have built.

Affordances and Desire Paths

A no parking sign, hastily attached to a pole by a pragmatic tinkerer

The image above depicting a no-parking sign posted on Stanford campus is an example of how users will satisfy their needs expediently, with tools that are available (aka “satisficing” ).  This signage probably isn’t the version that Stanford would officially endorse, but it works, it satisfied a need, and the person that devised this solution spent maybe a couple dollars in materials costs (I count 8 zip ties.)  

Websites powered by CMSes work like this too (at least the good ones do). Drupal is a powerful, flexible toolkit. Even when we package it up as Features and products, it’s still a toolkit underneath, and a natural process in a user’s development as they learn and grow with the tool is to solve their own problems expediently with what’s available, using tools they can reach. And our toolkit includes the equivalent of zip ties —super-handy, seemingly all-purpose tools whose affordances allow the user to apply them in multiple (sometimes surprising) ways.

Certain kinds of  vernacular architecture were innovation-friendly because they communicated their affordances to their inhabitants. “The lesson for the ages from three-aisled structures is that columns articulate space in a way that makes people feel comfortable making and remaking walls and rooms anchored to the columns”[4].   Is there a digital equivalent? What can we do with UX design to help our users see what’s possible, without letting them get into too much trouble? Can we design the user experience so that the tool teaches its users?

Design is human.

Design is about solving problems for people. As designers of tools we always strive to empathize with the people that use the tools we make, and part of that is making complex things simpler, but we shouldn’t sacrifice our users’ ability to innovate with our tools in ways we can’t imagine. There are things they know about what they need that we can’t anticipate. The NeXT engineers left Tim Berners-Lee the 32 bits of memory he needed to write a hypertext editor, which gave birth to the web as we know it. Now it's our turn.

We should always leave a few zip ties within reach.

 


Notes:

  1. Weaving the Web, pp. 28-29
  2. Make Space, pg. 76
  3. I see a direct parallel to Vernacular Architecture in what we commonly call “best practices” in Drupal development, and how that term can refer to slightly differentiated discrete practices in different locales, institutions, verticals, and communities of practice. Darwinian. We are finches.
  4. How Buildings Learn, Chapter 9
a face for radio Posted by Zach Chandler on Wednesday, April 16, 2014 - 8:00am

Dear Developers, if you follow these simple guidelines, your Drupal Features will be much more useful to institutions like Stanford over time. You will win friends and influence people. Drupal will live up to its potential, and there will be much rejoicing.

1. Small Features, Loosely Joined

For institutions like Stanford that have multiple Drupal projects all happening at the same time, spread across different teams, it is important to establish norms that make reuse more likely. For Features, smaller is better. The atomic unit for a Feature is the Content Type. If you do nothing else, make one Feature per Content Type and resist the temptation to put anything else in it.  Whatever else you got going on: Views, Rules, Feeds, Services, etc. keep all that stuff in separate Feature(s) that list the basic Content Type Feature as a dependency. To maximize its reuse potenial, your Content Type Feature should not itself have any dependencies on other Features*.  It’s common for developers to use a <prefix>_base Feature that bundles common site attributes (like image styles and variables) that all the other Features depend on.  In our case it’s better to either a) not do that, or b) make it easy to discover and undo that.
 

2. This is my prefix. There are many like it, but this one is mine.

One attribute that all highly reusable Features have in common is a prefix, consistenly applied. I have stood up a hasty prefix registry on techcommons (until we decide to make a better one). Each unit of the university should use just one prefix over time. This will take a little care and attention, but I have faith in us. Here are some of the existing claimed prefixes. If you have a small project inside one of these organizations, please use these instead of registering a new one:

  • gsb_ (Graduate School of Business)
  • soe_ (School of Engineering)
  • earth_ (School of Earth Sciences)
  • dor_ (Dean of Research)
  • stanford_ (Stanford Web Services)

To see the complete list, and to add to it, please visit techcommons.
 

3. Namespace them thar fields!

Many of you are already making Kit-compliant Features. That’s good! (We like Kit.) So please do read and follow the Kit spec for Features. We also need to extend Kit some.  Our primary concern is field name collision, or anything else that would prevent a Feature from being successfully introduced to a new Drupal site outside its original distro. Like most everything else in Drupal, we do this with prefixes (technically, for fields these are infixes).

Things we prefix:

  • Modules and functions (natch)
  • Content Type machine names
  • Views machine names
  • Fields
  • All the things

Example:
The Cantor Center is creating a Drupal Feature for their exhibitions. They know that prefixing is important, and they don’t want to collide with similar projects currently underway by the Department of Art and Art History or the Libraries, so they employ the prefix cantor_ consistently across all their properties, and edit the techcommons page to let others know that they have done this.

Content type: cantor_exhibition
Field: field_cantor_exhibition_image
View: view_cantor_exhibition_gallery

You’ll notice that we use a version of Hungarian notation, whereby the machine name indicates what that thing is. For field names this can be a little challenging due to the 32 char limit on field names (and Drupal uses up the first 6 with field_ ) but if we all stick to this convention our Features will get along with each other, and as a University and an open source community we stand to gain a great deal more over time as increasing number of these Features become Highly Reusable Features. (HRF? I’m trademarking it! I want a quarter any time someone says it!)

If we do nothing other than harvest the humble Content Types from our various projects, that alone is a huge win for us.  This point may get lost in some of the flashier Drupal applications being built these days, so it’s important to call out:  Drupal is a marvelous content modeling framework, and the Content Type contains a lot of important information about a particular domain or group that is highly shareable.  We don’t have a single, uniform higher-ed use case. We have hundreds of use cases. The Content Type emerges as an extremely relevant and legible artifact of prior work that we can learn from, adapt, and develop over time.  We are looking for development teams that are willing to join us in this endeavor (and show the perseverance to slog through overly verbose blog posts!).
 

Call me maybe

Any development team that wants to connect directly with me to discuss our Features best practices is more than welcome to do so! The absolute best time to do this is when the content model is just taking shape, before you make your first Content Type. There is one vendor team that already is doing all of the above consistently (you know who you are; thank you!) it would be amazing if we get to a point where everyone does.

 
*one obvious exception to the no dependencies rule is a Content Type feature that includes an entity reference to another Content Type. Dependencies aren't bad, we just want to remove unnecessary ones.
a face for radio Posted by Zach Chandler on Wednesday, November 27, 2013 - 1:15pm

Either we shape the the technologies that we use, or they will shape us.  Stanford’s commitment to the Drupal CMS enables more of us to think like engineers, embrace the Maker ethos, and craft our own tools.

“The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.”
Mark Weiser, Xerox PARC (1991)
“As much as we love the open, unfettered Web, we’re abandoning it for simpler, sleeker services that just work.”       
Chris Anderson, Wired (2010)

Drupal’s affordances “allow non-developers to do developer-like things” (quoth Rob Ristroph, ninja developer) and the Sitebuilder is a class of Drupal expert that doesn’t get the billing it deserves. Drupal allows more of us to behave like engineers — individuals that can apply technology and ingenuity to solve real world problems.

It is important that we technologists retain our status as Makers in this consumerist age of technical atrophy. By technical atrophy I am specifically referring to the trend of becoming mere consumers of services and products, rather than technologists that are fluent in the technologies we use and capable of understanding and modifying software to suit our purposes. 

The above quote from Mark Weiser is an astute observation, and I have heard it cited many times by designers aiming for the holy grail of invisibility as a marker of success. A good thing. But I don’t think it’s necessarily good for everyone. Invisibility-in-use is great for Users, but bad for Makers. Makers should know how stuff works, and grokking requires visibility.

The Appification of Everything

I went to SXSW Interactive for the first time this year, and I was struck by the marked focus on mobile apps.  There was still a Mozilla booth with a dude in Firefox costume and conspicuous Yahoo! and Google lounges and events (I seem to recall whole buildings sheathed in massive dropcloths emblazoned with brands), but in the rarefied world of SouthBy, it seemed that the cool had drained out of the web, and had been ceded to the appiverse. Seemingly everyone had a new app to promote, and the crowd was waiting expectantly for the next Twitter to be unveiled. Nevermind that Twitter was a web app first, people were panning for gold in native apps.

I have seen the projections for the growth of the mobile market, and I am aware of how important mobile devices are for web design. But still, it seems to me that, for some, the web has been occluded by mobile — which is shortsighted because native apps are just one aperture into the web.

The principal problem with the Appification of Everything (AoE) is that it accelerates the deprecation of the role of User to that of Customer and accelerates technical atrophy because it winnows the segment of people who can do interesting things with technology. It also embodies a fundamental misconception: that websites and apps are distinct from one another. Todd Nienkerk wrote a great blog post on the Four Kitchens blog recently that summarizes this problem well: Apps Are Icons.

Attributes of a Citizen-Engineer

To avoid a future where everything is super comfy, software always Just Works™, and the only device a full participant in the internet would conceivably need is a tablet full of apps,  we will need a certain kind of person, and we will need that person to understand his power and his purpose. We need Citizen-Engineers.

A Citizen-Engineer:

  • Has the ability to understand code, and learn new technologies, but does not have be a trained programmer
  • Can innovate within rule-governed creativity
  • Understands the basic principles of every layer of the stack, hardware and software
  • Can modify the tools they use
  • Has tolerance for imperfection
  • Has problem solving skills
  • Has expertise in a field other than web development
  • Values the commons of the Internet
  • Understands how policy can affect technology, and acts to protect freedom and innovation

A Citizen Engineer: The Drupal Sitebuilder

There is a startling array of configuration possibilities in Drupal using just the administrative UI, without writing a line of code, because core and module developers in the Drupal community have intentionally built power tools for us to innovate with. This is a particular quirk of Drupal.

Sitebuilder is a term that has emerged over time, and there may be some dispute as to what kind of skillset it includes (at some shops, a person with this title is a web developer, but I think most people think of Sitebuilder as an adept in the Drupal system, that relies mainly on savvy configuration and implementation of existing code written by others) but it has a special meaning in Drupal compared to other systems. That we have so many talented Sitebuilders is one of the least celebrated, yet most important attributes of the Drupal community.

The reason why the Sitebuilder is so important is that often they are experts in something else, subject matter experts that can use Drupal to model things that exist in their discipline, and since Drupal is also a collaboration platform by nature, the datasets that are created with it are ready-made for allowing communities to grow around the tool, or the practice that it encodes.

Some recent examples of projects that innovate using Drupal’s ready-made tools:

Try Hard Things

Richard Stallman, at a recent lecture at Stanford Law School, reminded us that users of Free Software assume a burden for the freedoms that they enjoy.  It is likely that a given open source system will not have a glossy, perfect user experience out of the box.  Instead of giving up, and defaulting to buying proprietary systems that seem to meet more of our needs right away with little effort, the Citizen-Engineer rolls up her sleeves and changes the rules. She knows that she has the ability to modify the system, and shape it to act more like she wants, and by contributing to an open source project she not only benefits herself and her immediate stakeholders, but potentially lots of others as well in a vast, sprawling commons that is the Internet. Being an open source software developer is harder than paying for a 3rd party service. Being a Drupal developer/sitebuilder is harder than, well, lots of other choices, really. But the future belongs to people that are willing to try hard things.

a face for radio Posted by Zach Chandler on Thursday, June 20, 2013 - 9:12am

I provide web project strategy and guidance for Stanford departments looking to hire a vendor for custom web development. My clients receive a full-service experience that includes business analysis, technical review, needs assessment, research and writing, agency recruitment, proposal evaluation, reference checks, forecasting, and is tailored to their specific needs. My clients are very happy.

However, this model does not scale. A comprehensive selection process can take 6 weeks, and I can’t work with everyone who needs help. Therefore, I intend to use this blog to share information  and experiences with the community about some of the basics of vendor selection that could help lots of people at once.

Because of the importance of Drupal in Stanford’s web environment —and the inherent dangers of handing a tool with such flexibility (and thereby margin for error) to a non-specialist— I choose to focus specifically on Drupal for this article, but I should probably write another one for general considerations when sourcing web design and development talent.  For today, I will keep it mainly on the Drupal channel, occasionally flipping over to the PM channel.

When selecting a vendor for Drupal work, these are among the things that I look for. Please read these tips before searching for a vendor or signing a contract.

tl;dr summary

  • Make sure your developer knows the Drupal API

  • Standing in the Drupal community matters

  • Examine portfolio and filter on the specialty suited to your particular needs

  • Require secure code

  • Check references

  • Seek competitive bids

  • Project Management and communication matter

Knowledge of the Drupal API

Drupal has a hook system that allows for any given component of how Drupal works to be overridden. It is fundamental that your developer understand this system. Masters of this practice can do amazing things. Those who ignore it break stuff.

A common mistake is hiring an expert PHP developer to build something in Drupal. They will have a solid understanding of the underlying technologies, and will be naturally inclined to seek expediencies (a.k.a. “hack core”). That’s bad. An expert PHP programmer could easily become a Drupal developer, but they will need a guided tour before they dig in. The value of this approach may not be apparent or convincing to a developer at the outset.

Standing in the Drupal community

Your preferred agency may seem skilled and professional, but who are their developers exactly? All Drupal developers have profiles on drupal.org. Ask who the lead developer on a project will be, and ask for his or her drupal.org username. You can then look him or her up and discover what contributions they have made to to the Drupal project.

Is your agency a member of the Drupal Association? Do they participate at DrupalCon and Drupal Camps? Do they sponsor these events? Do they contribute code back to the open source community? These are all things that matter.

Experience shows that standing in the community can have a direct effect on project outcomes. Drupal is not one project, it is thousands of separate projects (called “contrib” for “contributed modules”), a constellation that orbits one central body that is Drupal Core. This is one of the big reasons that Drupal is so flexible and so powerful. If your custom project pushes the boundaries of what is possible in Drupal, and new functionality is needed to succeed, a dev that is well-established in the contrib space will be more successful in getting patches accepted by  module maintainers.

I should acknowledge that not every agency broadcasts their contributions, and plenty of expert implementers don’t have have numerous commits to the Drupal project. I know some stellar developers that have light-looking d.o profiles. It’s not a litmus test, but if the lead dev for an agency doesn’t even have an account, that’s a red flag.

Portfolio and sub-specialty

Not all web projects are the same, and often no two Drupal projects are exactly the same. Some projects require sub-specialties. How strong is your agency of choice at theming? devops? features? installation profiles? custom module development? evaluating available contrib options? commerce? CRM? SEO? An agency that is excellent overall might not be top-of-list if their skills don’t align with your project requirements and priorities.

Caveat Emptor: do NOT hire a pure marketing/advertising agency without a qualified Drupal development team, and if you hire a print designer with no web experience whatsoever, I guarantee that you will be the owner of a hot mess in about six months..

Secure Code

Drupal is a very secure system that is used widely by such entities as the Department of Defense and the White House. The core project is very secure when kept up-to-date and implemented correctly. Drupal also has its own Security Team that responds to exploits discovered by the community and keeps us busy applying code updates. However, as soon as we introduce a custom module—as large projects almost always do—we must be certain that the vendor we engage is well versed in best practices for writing secure code. Simply asking your prospective vendor what they do to ensure that their developers are up to speed on web application security is a step in the right direction.

References

Has your preferred agency worked at Stanford before? If so, which projects, and what was that experience like for the Stanford client? Some of the best agencies in the business (to my chagrin) still have not worked with Stanford, so this shouldn’t really be a barrier to entry; however, you should check with colleagues in order to benefit from institutional memory.

Competitive Bids

The Procurement Office requires competitive bids for development web development work. Stanford faculty and staff have a fiduciary responsibility to follow Procurement guidelines, and should not abuse the sole source justification. Sole source certainly has its place, but we should be rigorous. If you are tempted to select a vendor based mainly on a prior relationship, slow down, evaluate the project requirements, and take stock of whether you are asking them to operate outside their area of expertise

Client Communication and Project Management

In the early days of my vendor relations career, I prized technical chops over pretty much everything else. That was a mistake. Projects can fail for a variety of reasons, technology being only the most obvious. Successful projects are built on three pillars:

  1. Technical proficiency of the designer, developer, or agency
  2. Project Management (PM)
  3. Client communication

I used to put all of my eggs in basket #1, but have since learned that this stool needs all three legs. Project Management is a highly technical skillset, and the people who are very good at it are rockstars. Not everyone can do it well. A technical PM is an invaluable asset, especially if they can provide deft pushback when needed (and it will be needed at least once on every single project).

I have also learned that PM and client relations are separate proficiencies, and we need both. PMs can be extremely efficient communicators, but may not be best suited for the client relations role, and having an additional point of contact separate from the PM workflow is ideal. If it is an especially huge or complex project with a large stakeholder group on the Stanford side, it is recommended that you have a dedicated PM on the client side to work with the PM on the vendor side. I realize this sounds like overkill, but experience shows that staffing at this level can really pay off and take a great deal of stress off the Stanford project lead (a.k.a. “you”) and save money in the long run.

Inconvenient Truth Time

It is a stark fact that doesn’t get talked about much, but for projects that experience difficulty, clients are in fact the problem at least half the time (this is an industry-wide phenomenon and is not unique to Stanford). Technical and creative projects tend naturally toward entropy and confusion, which has to be mitigated on purpose. An agency that possesses a distinct client communication proficiency will succeed more often. Clients are not obtuse luddites, they may be brilliant minds at the top of their chosen field; it’s just that they don’t do web-related work every day, and sometimes need a congenial expert guide to keep the ship on course. If your agency has one of those people —in addition to a skilled development/design and strong PM— then you are in good shape.

Conclusion

These days many units at Stanford are opting for Drupal at project outset because of the great amount of resources and expertise that we have accumulated as a University in this technology, and, I wager, the inherent power of the Drupal framework. Drupal is complex, and hard to do well especially if you don't want to forward that complexity to the user. Because Drupal is complex, it is important to engage a bona fide Drupal agency if your project calls for custom solutions.

Lastly, if any Stanford unit has a bad experience with an agency, please let me know. If your unit has a good experience with an agency, also let me know. We want to learn from mistakes and successes alike, and pass that information on to the community.

Good luck with your project!

a face for radio Posted by Zach Chandler on Thursday, March 7, 2013 - 9:56am

At SWS, I have developed an improved method for vendor selection over “traditional RFP”, but it can take a little explaining—to clients and vendors alike—as to why it’s better, and why its worth the time investment.

Why change?  To be honest, a couple of years ago we were pretty happy with the traditional Request For Proposal process, and didn’t feel the need to change much of anything. It was a useful tool to articulate a specification for web development services, publicize this opportunity, and review the resulting proposals based on their relative merits.  It seemed straightforward and fair.

Problems became apparent when I started listening to industry leaders whom we at Stanford regard as partners in building the future of our web platforms.  They hate RFPs. With a passion. Publicly.

So, I started talking with some of them about what a post-RFP world would look like in really specific, nitty-gritty ways. If we were to replace the RFP with something, what would that thing be? I’ve spent the last year and half on this problem, and have formulated what appears to be a viable alternative. And I’m going to share it with you nice people because Stanford supports open source, open access, and information wants to be free.

Defining the Alternative

On this post-RFP frontier, I begin with a document that I call an Expository Sketch, which is not actually a replacement for RFP by itself, rather it is the first step (of many) in a rigorous and thoughtful process that can take 4-6 weeks. The premise of an Expository Sketch is that we should not start with a specification, rather a conversation.

RFP represents document-to-document communication:  Here is the specification that we, the client organization, have produced. How much will it cost to procure these services from your company to build this exact thing?

But what if our assumptions are not completely valid? What if we can’t see around all the corners, or see new possibilities of connecting with new methodologies or technologies? A pre-emptive spec locks you into your current best guess ... and the web changes faster than that.

Instead, the Expository Sketch is an invitation to open a dialog about the parameters of a  project. Though it may contain something that looks like a specification (and could be used as such) its purpose is to define how we on the client side are thinking about the problem space, and to invite commentary from the vendor side. To underscore this difference, any proposed build-out in an Expository Sketch should come with a preamble:

"The following is not intended as a prescriptive specification, rather one plausible path to solve for this problem space, to convey a sense of what we are thinking in terms of scope. We recognize that Drupal developers and designers are creative professionals, and we look forward to your input and interpretation. We have no intention of tying your hands. The following are suggestions, a baseline."

By setting the tone in this way, you open the door for surprising results. If you start with, and insist on, a hard spec at the beginning, that's likely the best you will get. By being open to the ideas of others, and stating the problem you want to solve rather than telling the vendor how to solve it for you, you may find that the outcome can be far better than you imagined.

The final attribute of the Expository Sketch worth mentioning is its focus on exposition. At best it will call out the constraints and potential gotchas of a project as we can detect at the outset. (It’s surprising just how many of these are detectable in the beginning if you know what to look for.)  Even if it might resemble an RFP, the Expository Sketch differs in focus: instead of calling out exactly what we expect from the developer (that comes later, with the Statement of Work), the Sketch embraces collaboration and focuses on exposing all parameters as openly as possible, for the benefit of everyone, client and vendor alike.

To some clients this approach will sound risky —how can we start a project without stating specific requirements that the vendor must fulfill? Actually, you still get to do that at contract time, what makes the Expository Sketch different is that we don't start with hard requirements.

No Spec Work

Just to be clear, I take a hard stand against spec work and will never ask for it. (No, not that spec, the other spec: speculative work.) No project I am associated with will ask for up front work to qualify a vendor, and the idea exchange that the Expository Sketch engenders has nothing to do with surreptitiously mining ideas from vendors who never had a shot a winning a contract. There is a special circle of hell for those people. Spec work, and its abuse, is one of the reasons why agencies have soured on RFPs. Agencies can spend 40-100 hours or more (that's real money folks!) writing proposals, and to ask them to do so only to acquire free work from them is unethical.

At Stanford Web Services I do a whole lot of homework on vendors to qualify them for work at Stanford before ever inviting them to bid on a project.  We do not broadcast RFPs (unless the law requires it, in the case of government contracts). Instead I send a personal invitation to bid to each shop, and I start with a very short list. Stanford requires 3 competing bids, but I try to keep the list as short as possible (I have a version of the Hippocratic Oath: "waste no one's time.") If an agency is invited to submit a proposal for work at Stanford, they have my personal guarantee that they have a fair chance to win.

a face for radio Posted by Zach Chandler on Wednesday, December 12, 2012 - 3:53pm

In my role as Web Strategist, I enjoy a privileged perspective on the state of the web industry in higher ed. I get an inside look into the new methodologies employed by some the best agencies in the business. Agile project management is a growing trend, and one that different vendors employ in different ways: some scrupulously follow the Scrum method and all of its rituals, while others prefer a “hybrid” approach. In this article I gather some of the lessons learned from some of the largest web development projects at Stanford over the past year, in the hopes of sharing them with others that are about to embark on their own projects.

What is Agile exactly? At its core, Agile project management means that work happens iteratively, and that the Product Owner (the client) has the ability to change directions, and doesn’t have to define everything in the beginning.

This all sounds pretty wonderful right? Well, it can be. At SWS we are using some Agile methods in our in-house development, as well as in vendor projects. This has been incredibly effective for our team, as Agile has the ability to stand up prototypes very quickly, and therefore at a reduced cost.  When the machine is working well, communication channels are established, and everyone knows their role, Agile can yield incredible results.

In other cases Agile doesn’t work very well, and it often comes down to the client, their culture, preferences, and customary way of working. On the vendor side it requires an expert PM and careful monitoring of budget burndown.  A lot of things have to go right. So, does Agile work for web projects at Stanford? Will it work for you? Maybe not. One important part of Agile development that takes some getting used to is that there may be no firm specification at the beginning--the requirements take shape over the course of the project, and can change based on evolving needs. At Stanford we typically do not use pure Agile for web projects, in part because of institutional preferences and ways of working.  Even when we engage in Agile methods (mostly we use Scrum), we have an endpoint in mind, and a set of requirements articulated at the end of a Discovery phase.

Minimum Viable Product

A key concept in Agile development is Minimum Viable Product (MVP -- the nature of which is pretty evident in its name).  MVP is a barebones version of the project, a prototype that includes all the must-have functionality.  If the Agile process has gone awry (due to miscommunication, excess communication, etc.), MVP is all we will have at the end of the project.  If the Agile project has gone well, we will have MVP very quickly, and many rounds of subsequent improvements. In a recent project with SWS, we engaged with a vendor in a T&M (Time and Materials) contract that spanned a maximum of 10 weeks.  The team was very efficient, with clearly defined roles; we got to a functional prototype in the very first sprint (!) and we essentially reached MVP in the very next sprint (in this case sprints were 1-week long).  
Bottom line: we achieved what we set out to do using only 20% of the allotted budget.

Ugly First, Pretty Later

A Minimum Viable Product is, well, minimal.  Agile focuses on building a rough version as fast as possible, and then adding more and more each sprint until we have a polished final product.  The website will be ugly for a while. This is normal. Your developer will be focused on the underlying content and data structures--content types, taxonomy, user roles and permissions--and pretty doesn’t usually make it into the first sprint.  It’s important to know that from the outset.

Working with a barebones prototype and incrementally improving it can be a challenging proposition for clients because it focuses on what’s under the hood first (which is harder to appreciate), and the visual layer comes into focus gradually. This is especially challenging when we need to communicate progress to higher level stakeholders--which we should always do.  For this reason, Waterfall methods, in which a discrete design phase precedes development, often make more sense for institutions like Stanford.  The challenge is to discern why Waterfall works better for client communication, and borrow what we need from it.

What Works for Stanford

Regardless of the project management methodology employed, getting stakeholders on board with the direction the project is taking --in particular the creative direction-- is vitally important.  Project leads (cf. Product Owner) are typically empowered to make all the decisions in the development of the project, and approve invoices, which can make it challenging to know exactly when we should check in with the higher level stakeholders on whose behalf we are acting. At minimum, I recommend that we seek signoff from stakeholders for visual design, which tends to be a component that generates a lot of feedback, and people tend to get more involved around page comps.  There are other key moments that might also be good to gather feedback (such as final wireframes, and style tiles) but comps should be shared at minimum … and here is where we can start to have problems with Agile.  

Agile projects might not even produce comps at all, and some shops have begun “prototyping in-browser” rather than wasting time with lo-fi wireframes or hi-fi HTML prototypes. For client communication and signoff, we need to take a page from the Waterfall playbook. Even if the developer is prototyping in-browser we still need some form of visual to share with stakeholders for their feedback.  In the event that your Agile process skipped these shareable artifacts, we still need to come up with something portable to circulate (likely via email).  A jpeg screenshot of the site (assuming that it has crossed the ugly->pretty threshold) will suffice. This may seem backwards to some, but experience shows that a jpeg comp is an important communication tool for Stanford clients (and I would wager for many other institutions and clients in other verticals as well).

Be Careful What You Ask For

The Product Owner of an Agile project is empowered to change or refine direction at the end of any given sprint (an intense period of concentrated work, usually 2 weeks in length). That is awesome. It’s also dangerous.  Most projects have fixed budgets, and we have to be very mindful that for every new feature that is added midstream--each sprint spent on researching the applicability of that new javascript library that didn’t exist at the start of the project--those are all billable hours, and we are choosing to give up something else as a result.  For this reason, Agile projects cannot be beholden to a specification that was minted at the outset.  Product Owners must know that they have to exercise their powers of prioritization judiciously.

Summary: Lessons Learned

  • Formal agreements, formal process structures are important.  Vendors that have well established PM structures and habits tend to be the most reliable on Agile projects.  However, if they use terms like “Agile-ish” or “hybrid agile” it doesn’t mean that they don’t know what they are doing. We have to dig deeper, there is no litmus test.
  • Stakeholder Signoff Plan. Have a plan for how you are going to communicate with stakeholders and keep them in the loop at an appropriate level.  Avoid design-by-committee. Luckily everyone thinks that is a bad idea … even committees.
  • RACI Responsibility Matrix. In a recent project SWS was able to hit the ground running because we drafted a formal responsibility matrix that eliminated the possibility that anyone wasn’t clear on who was doing what.
  • Fully sized and ready backlog. Scrum projects work by atomizing work into user stories that reside in a backlog, and are prioritized by the Product Owner.  If the stories in the backlog have not been properly “sized” by team consensus, you may have a problem on your hands. Insist on a “sized and ready backlog” if attempting Scrum with a new vendor.
  • T&M is okay so long as there are checkpoints, and only for trusted vendors
  • Burndown charts are an important way to make sure that we are not surprised by a budget shortfall.
  • Project Managers are the most valuable resource for overall success, and really great PMs are hard to come by. If you have one, hold on to them! The best ones not only keep everything moving smoothly, but also provide pushback to clients when needed. At Stanford we don’t like pushback, but we need it.  

So, is Agile right for Stanford? Yes.  Assuming that Stanford clients go into a vendor contract with a clear idea about what it means to be part of an Agile project, are fully cognizant of the hazards, are working with a trusted vendor, and have a plan for engaging stakeholders, Agile is an efficient, cost-effective, and fun way to work. It is also worth noting that the Waterfall method is still relevant, tried and true, and is proven to work well at Stanford, so not every project should use Agile.  We are fortunate to have a number of excellent web vendors that are sensitive to our needs as clients, and can adapt their process to help us build the next generation of web experiences for our users.

Subscribe to Zach Chandler's Blog Posts