And the Process-Oriented Shall Inherit the Earth

Are you process-oriented or are you results-oriented?

Creating new museum projects is becoming more complex. The development of exhibitions, websites, and social media outreach require multiple departments to work more collaboratively than ever. Content creators must communicate effectively with web producers and editors. A change of text can require a change of context: site architectures may shift and everyone must be aware of how these changes affect the development process and project timeline as a whole. But who’s watching over this complex process? And why is this even important? As technology and our workflow changes, paying close attention to our process becomes more important. So let’s start with Glenda’s question: Are you a good witch or are you a bad witch? I mean, are you results-oriented or are you process-oriented?

Museums, like most organizations, are results-oriented. Directors want projects to come in on time and on budget. While we all want our projects to succeed, benchmarks for success and engagement are constantly changing. This makes gauging our results more difficult and often, getting there even more so. These new paradigms constantly require new ways of planning. What worked last year may not work or be valuable this year. To paraphrase the old real estate adage: the three most important words in this environment are context, context, and context. The process we use to reach our goal is becoming as important as the results.

Often, project management seems like the parable of the twelve blind men. Each person on the team is looking at the undertaking in their own way, based on their own part in the project. Stakeholders have a vision of what they want and give technologists a list of deliverables. Technologists take that laundry list and put it together to find the right tools for the project. But technology and the mission of our museums are fueling changes in how we approach this process. And this affects how we, as technologists, approach our jobs.

Results-Oriented: How quickly and efficiently can we complete the project. Process-Oriented: Visualizing project development from beginning to end.

Put simply, results-oriented managers have a goal: How quickly and efficiently can we finish the project? This is traditional project management where the primary emphasis is to get the project done on time, on budget, and within scope. While process-oriented people look at things a little differently. For them success rests with visualizing project development from beginning to end to finish on target and on time. This is what I call meta project management. The primary emphasis is how are we going to obtain our goals? Both approaches are necessary for success. Without a goal, there is no project. But once you have a goal, you need to know how you’re getting there.

Is this what I’m talking about?

No, not quite. This is what I’m talking about: managers and stakeholders need to be aware of a broad project scope: are we on target? They have no time to drill down to the details. Workers tasked with developing technology projects have a narrower scope. They need to know what’s happening at all times to monitor benchmarks, troubleshoot, and, ultimately, success. That being said, process- and results-oriented project management styles are not always mutually exclusive. We often play both roles throughout the project lifecycle. And technologists must be aware of both approaches. We want the project to succeed and we want our managers and stakeholders to feel confident about the process.

As new technologies encourage new types of projects, the roles of museum staff are changing. And, if we’re not careful we will slip into that elephant paradigm. Here’s a personal example: When I was asked by my boss “How’s the project going?” she wanted to know is it on target? But rather than give her a direct answer, being focused on the specifics of where we were at that moment, I wanted to tell her the issues I was dealing with at that particular time. I was focused on the process. She was focused on the product. I took note of this disconnect and decided to take a different approach the next time. A few weeks later, when she asked me for an update I answered her with the information she wanted (“the project is on schedule”). Once she had what she needed she was more open to hear about the issues I was facing at that specific time. It was a win-win.

Technology is accelerating organizational change. And this affects our development process. By focusing on this process we can become more agile in our project development. And we can better anticipate potential problems and roadblocks. But for technologists, this can be is a Sisyphusian task. In 2010 I presented a paper at the Museums and the Web conference called Clearing the Path for Sisyphus: How Social Media is Changing Our Jobs and Our Working Relationships. In it, I mentioned seven roles technologists were now playing in the social media-focused workplace. We are:

Advocates: advocating for change
Collaborators: working with others for change
Community Organizers: working to build communities both with our visitors and within our organizations.
Realists: Accepting the often slow pace of change and resistance to new ideas.
System Analysts: Looking at the process of introducing and developing new ideas.
Negotiators: Negotiating for change. Building alliances within our organizations.

And finally, we are Opportunists, looking for new ways to approach the process whenever we see an opening. We can also apply these roles to project-management.

A Traditional Microsoft Project Schedule

Dorothy had the Yellow Brick Road as her roadmap. We have Microsoft Project, an application only a traditional project manager can love. As a technologist, it’s awfully confusing and easy to get lost. Of course, someone needs to be looking ahead. But these days it’s not just the project manager. It also is the project technologist.

In a talk Nina Simon gave at the Smithsonian in 2009, she stated science museums engage their audiences much more than art and history museums. She wasn’t sure why. Science curators, I tweeted in response, are scientists whose experience is rooted in collaborative inquiry. Engagement is an important part of their process. However, art and history curators come from disciplines where personal research is the keystone of their research. When they arrive at the museum as curators they are less likely to have worked in a collaborative environment. Does this make a difference in how we develop projects that encourage visitor participation? If so, how can we foster a more collaborative and process-oriented development environment? The key is to remember the roles we, technologists, play and take the opportunity to use them throughout the project lifecycle.

A Case Study: Oh Freedom!

An Artwork Page from the website Oh Freedom!

In 2011 the Smithsonian American Art Museum, along with the National Museum of African American History and Culture completed an online project called Oh Freedom! The site was developed to help middle and high school teachers use American art to teach African American civil rights.

In our initial meetings the stakeholders shared what they wanted to see on the site. The number of necessary elements on each artwork page included not only a large image, but information about the work and the artist, related material, and questions to help students look at the work. As I listened, I mentally prioritized each piece of information. Most importantly, they wanted teachers to be able to collect and annotate information on the site for future use using a “My Collection” widget.

The challenge was to get them this feature with a content management system (CMS) that would also work for the other important elements of the site. This was where I began because this would be the most difficult to fulfill. Not too many CMSs offer this “My Collection” feature. And the ones that are out there haven’t always been impressive.

One of the only CMSs I found was Omeka, and open source system developed at George Mason University in Virginia. Omeka was developed specifically for museum collection and exhibition websites.

As I mentioned the stakeholders wanted an abundance of information on each artwork page so, in order to make the page accessible to users I used an accordion script to hide and reveal the details of each section. In addition to the “My Collection feature, another important element on each artwork page was “Related Material.” Secondary sources allowed for a broader look at civil rights and American art.

Left: an expanded view of the related material. Right: Omeka backend for managing this information. In an early version of the CMS there was no way to reorder the list.

During my initial testing I noticed an important limitation in Omeka’s ability to handle and display this related information. Once you input the data and images you could not reorder them! Therefore, all data needed to be uploaded in the order it was to appear on the site. In subsequent versions of the CMS ordering was allowed. However, the plugin for the collection feature wouldn’t work with these newer versions. So, given the priority of the collection feature I would have to stay with this earlier version of Omeka.

I had to see the entire scope of the project from above.

I needed to convey this challenge to my stakeholders immediately as it had both immediate and long term ramifications for the project development. Constant updates to a site before launch is common in web development. I foresaw major problems if I didn’t get all the information in the right order and all together. And I needed to communicate this to the stakeholders. We needed to create a detailed chart showing the exact order of each group of related material for every artwork. If I had to start from scratch every time they wanted changes that would impact the timeline for completion.

Technologists have to be aware of multiple processes throughout the project . I had to manage my own development process but I also had to communicate to my stakeholders the limitations of the content management system and how that would affect their work and the overall project management timetable. When the stakeholders complained about the software’s limitations, I reminded them the reason we used it was to gain that “My Collection” ability. The only other way to do this was to create a CMS from scratch. And we didn’t have the budget or the time for that. So, as part of this process, technologists need to be ready to justify their choices when issues like this arise.

This process-oriented approach to project development is mirrored in the changing relationship between our museum and our visitors. Rather than focus on just the results of the art making process (the art), we are also focusing on process as outreach through social media, behind-the-scenes activities and conversations with our patrons.

The strategies we’ve employed to engage our audiences can also be applied to how we approach project management. The key is to remember the new roles we technologists play and take the opportunity to use them throughout the project lifecycle. And slowly we are pushing that Sisyphusian boulder up that hill. So let me return to where I started and leave you with this question: when are you process-oriented and when are you results oriented?

Originally titled And the Process-Oriented Will Inherit the Earth, I presented this talk at the 2012 Museum Computer Network Conference in Seattle, Washington.

Creative Commons License
© 2012-2018 Jeff Gates. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 4.0 License.

© 2001-2018 Jeff Gates ISSN 1544-4074