When I was a kid, I tried several times to make a product from the bowling pins my father swapped out of his bowling alley every summer. I bought a used lathe and I came up with ideas from mortar and pestle sets to small planters. Pictured to the right is a paperweight and paper clip holder. I would sell these things door-to-door, starting with a neighbor. I would always be excited and a bit nervous as I began the sales process. Sometimes, the initial feedback was negative, like when people realized that a top-heavy paperweight is an accident waiting to happen. This week, I had that same queasy feeling as we delivered our first homemade SharePoint solution.
Eight months after rolling out our workflow-driven process to manage engineering inspection reports, and three months after perfecting that process on the heels of a post-implementation review, we unveiled the management dashboard for the head of the department. This guy manages a group of engineers, so to say that he’s case-hardened is an understatement. We were optimistic, given that he had defined a few general concepts that he was interested in, but we were also a little nervous. After all, this is the first time we had built a dashboard. I have mentioned before that the hard part of introducing technology to people is getting the design right. It’s hard because you don’t know enough about their business to know how they manage it, and they don’t understand the technology well enough to know what to ask for. In an agile environment, you can work from a build-test-review-redesign cycle that keeps things flowing, but that process didn’t suit our circumstances. In this case, we needed to keep working while the customer travels and conducts business. He didn’t have a lot of time to interact with us. This time, we got a “here’s what I want” speech to be followed a few months later by a “let’s see what you’ve got for me” meeting. Fortunately, I have a resourceful team.
We took a pretty simple approach for a dashboard; low on glitz but high on useful. We worked from a web part page with four columns which gave us a pretty good canvas. The left column holds the aggregate statistics about the current activity, including the things that might be going off the rails. The right column presents the historic view of this process, including the reports we are back-filling into the library. In the center is a group of detailed activity by engineer – one column for the current year and one for the prior year. In addition to presenting the information requested, the parts we assembled illustrated the key things we wanted the VP Engineering to know we can do, including:
- We can count things based on metadata and content type.
- We can perform date math on various status milestones. As I read that, I feel cheated, since it took a lot of work to figure out some of the bits and pieces of date math.
- We can create a wide variety of views that let you quickly drill down into the details behind a particular statistic.
- We can group things by person, type, facility, date, or any other attribute you like.
- We can perform basic math and logic functions like Average, Total, And, Or, Not, etc.
- We can use fonts and colors to draw your attention to certain elements (although we didn’t spend a lot of time proving this).
Jane Zupan at Nuxeo introduced me to a phrase that I love – Content-centric Applications. I told her I was going to steal that phrase to describe this process; because this is a business application. It just happens to be gleaned from the normal processing of reports that used to be tossed onto a virtual heap called the K: Drive. This is truly the beautiful part of SharePoint, the fact that we can collect, store, manipulate and display data about a process during the normal course of a business activity, and then turn that data into information.
Drawing conclusions from the demonstration, I’d say we met our goals. I counted at least three “I like that’s” and a couple of “nice’s”, and the all-important “whoa, what the heck is going on there?” That last observation led to a request for a few changes, but the request itself indicated two important things to me: 1) The VP understood the tool we had given him, and 2) He had begun to understand what else we could do. That’s a win as far as I’m concerned. We have a little more work to do before we can put this project in the “done” column, but we aren’t throwing anything away and we aren’t far from the bulls-eye.