Proximity Revisited

imageEarly in the life of this blog, I wrote several posts about ‘proximity’ and how important that attribute is to the user experience. I was recently reminded of that fact, and I realized that I my previous examples were too limited.

I was talking about designing a home page or a site page with all the appropriate web parts and without any of the inappropriate web parts. So, if you need to see a task list and a calendar, both of those should be represented on the page, not just sitting over in the quick launch area. Conversely, if you don’t want to have a picture on your site, then you should delete the one of those pretty people.

I also mentioned proximity in association with building dashboards. Having everything that you need being available at a single glance is the key benefit of a dashboard, so I guess my emphasizing proximity wasn’t much of a revelation. I also talked about proximity in terms of business process automation. As our engineers work though the recommendations resulting from their inspections, we tried to give them a view of each recommendation’s life-cycle that was meaningful.

It sounds like I covered all the bases. But, you know that I’ve never written a blog post with less than 250 words, so I must have missed something.

Earlier this year we built a payables process in SharePoint. People can select a vendor, enter a payment request (invoice) and spread that invoice around (allocate) to all the various GL accounts that are affected by it. For example, when we buy a new laptop for someone, we might buy them a case. Those are different types of expenditures.

I have always looked at accounting from a “money in” or “money out” perspective but our accountants seem to be in agreement with my Management Accounting professor – you have to pay attention to stuff like this.

Anyway, the system does all of that stuff reasonably well but there are a few things that the accountants wanted it to do better. Fortunately, one of the women in accounting is also working part-time with my team. One of the things she told me that they want isbetter views of the transactions at all of the various points. They have a view that shows payment requests that are pending, requests that still need someone’s approval, payment requests that are approved but not processes, as well as requests that have been paid and requests that were voided. Seriously, money in / money out works a lot better.

When I sat with her to find out what they wanted, Iimage experienced that old familiar feeling. The presence of that gap – the gap between what people can imagine and what they can’t. In this case, that gap separated the end users from what we SharePoint folks know as Data View Web Parts. As we work together, we are bridging that gap.

She said that they need more detail in the view(s). When I asked “why?” she said “sometimes, we need to know things about the vendor, or we need to know what GL accounts had been affected by this payment.” That made sense, except for the “sometimes” part. I don’t like views that show things that are only needed sometimes. I prefer views that show what you need ‘all the time’ but can be made to show what you need ‘sometimes’ on demand.

I wired up a imagelittle example of one view with the addition of two Data View Web Parts. One web part contained more detail about the payment request and one contained more detail about all of the allocations. I connected those web parts – OK – I really want web part to be one word…webpart, why can’t we just call them webparts – Sorry, I just had to say that. I connected those web parts to columns in the view. SharePoint easily let me show those columns as links, and now when they want the additional detail, they can click on the link and populate the web parts. If they click on the payment request ID, they get its details and its allocations. If they click on the amount, they just get the allocations. Easy-peasy.

To keep all this stuff proximate, we also have to constrict the original view by limiting the number of rows it contains. Most people hate paging, so I gave her an array of options to consider. All Payments, All Payments This Month, All Payments this Quarter, and then of course, this year, last year, etc. I showed her how we can set the page limit and how we can dynamically filter the list to render things like All Payments for a specific vendor. Then, I gave her a homework assignment – go back and sketch out the perfect view. Next week, I’m going to help her build that perfect view. Maybe then I’ll have a better illustration.

Disposable SharePoint

clip_image002I was pretty sure that I have written about this subject before, but I can’t find it so here goes. One of the things I love about SharePoint is one of the most often overlooked features – the fact that sites can be destroyed. When I say “destroyed” I mean exactly that, deleted, eliminated and removed from use. When I say “overlooked” I mean that we are usually focused on building sites to support an ongoing need or to automate a permanent process; I mean that we are thinking long-term or permanent. In our case, it’s because we tend to focus on Content Management solutions as opposed to playing to SharePoint’s strength of collaboration.

This week, we started the process of setting up a new temporary site, just as I was getting close to eliminating a similar site. Both sites were built in support of a systems development effort, and both benefit from several of SharePoint’s out-of-the-box technology.

The older site was built to organize documents related to a major redesign of our policy rating system. We used SharePoint to hold spreadsheet models, sample reports, SQL Select statements, documentation and we even used a SharePoint wiki to design changes to a user interface. We had a discussion list to track problems and potential solutions and we had a task list to keep people aware of pending deadlines. Today, as we are beginning to build out a more comprehensive site for our underwriting department, we are moving the useful artifacts from the development site to a permanent home. Soon, we will simply delete the old site. I must say that I wish SharePoint had some of the features of my daughter’s old game, Kid Cad, which let you delete structures by running a bulldozer through them or by using explosives. Microsoft could have at least added some sound effects to list, library and site destruction.

The new site will be used to help us as we design and develop a replacement for our foreign reinsurance management system. Right now, we are simply providing access to some reports that are being used to verify our data conversion process. As the system grows and as we start breaking ground on design issues, we will likely expand our use of SharePoint. This makes sense for a few reasons.

Proximity – If you’ve been reading this blog for even a little while, you knew that was coming. Having the things you need clustered together is a good thing. People like being able to find everything about a project in the same general area, and SharePoint allows us to quickly assemble highly functional little areas.

Feels Like Home –Yeah, I’m dreaming, but people are getting used to SharePoint and we are starting to benefit from the fact that they generally know what to do to get from A to B and how to get back to A. That may not sound like much, but navigation was a big complaint early on, so either people have figured it out, or they’ve stopped complaining. We have already delivered some reporting solutions to this department in SharePoint, so I think the feeling of familiarity will actually help us.

Easy to Delete – I have been doing systems development for 35 years, and one thing that hasn’t changed is the amount of stuff that gets generated. Not only do we create a lot of tables, diagrams, reports and data, we tend to spread it around, and forget where we put it. I am reasonably sure that I could find documents related to development projects from the early 1990’s if I looked hard enough. When we do tear this site down, just like the one I mentioned earlier, it will go in one smooth motion.

SharePoint sites can be made to stick around and serve future employees, but they can also be built for a single, temporary purpose. That’s one of the good things about this platform. Unfortunately, humans have a tendency to hold a certain pride of authorship that causes us to keep sites after they have served their purpose. We tell ourselves that “this data might be useful someday…” or “we may need to show this to the auditors…” or “we may want to review this when we make the next change…” Those aren’t hypothetical; I’ve said all three of them before. If the site is good, make it a template, and then light the fuses.

Managing Complex Projects – Part III

When I was managing projects as a consultant, life was great. Our work plan defined our role, and, when we got to the end of that plan, we were on a plane or on the highway home. Our workpapers were bundled and archived and the client… well, they were no longer my concern.

These days, projects don’t really end for me. They cycle, as I described last week, from “under construction” to “in use” to “planning for maintenance” and the types and amounts of information change as that transition occurs. Also, the requirements for archiving information are different during each phase, and these requirements have changed over time. As we did last week, let’s look at a few examples of the kinds of activity this project includes, the information management required and how SharePoint helps us meet those requirements.

Development Now & Development Later – System development is like the weather; there are intense periods of activity followed by what we would call “normal” a.k.a maintenance, as well as periodic dry spells. The only difference is developers enjoy storms and dry spells and despise normal. The often overlooked requirement, is the cycle-to-cycle communication. Maybe we put a band-aid on something today that needs surgery in the future. Or, maybe we added data or transactions today that should be reflected in screen or report changes down the line. But did we pass this information to our future self?

I know our track record of documenting these things has been poor because I found evidence of these types of changes but little in the way of documentation. The next developer will be luckier; I am leaving a trail and not just a pile of notes. The Custom Lists I created during development include references to changes that may/will/should impact future development. Requirements generated along the way have been documented in two ways. First, each completed task has a HTML text field called “Remaining Activity” – I love that this can include links and pictures so I can include a screen-shot if it’s helpful. Second, if the requirement is more complicated than tidying up some code, I can add it to a list of “Development Tasks” and create a new list item in the outstanding requirements list.

What We Keep For Auditors – The other people who want to know about our development efforts are our financial auditors. Mostly, they want to know that there were controls in place around the development process and that adequate testing was performed. They may ask this question this year, regarding this specific system, or they may ask two years from now regarding systems development in general. We’re keeping our design, our models, our test data, our test results and our database change log for them to review.

What we keep for documentation – Some of our experience in development will impact the users of this system. Rather than leave them to figure that out, we are collecting information as we go that needs to get woven into their documentation. For example: we sometimes build in support for transactions that rarely occur. Our test data is probably the best example to use in documenting these transactions, so having the ability to link the feature to the document and to the test data is very helpful. What we keep for this purpose also helps us with training.

As I have suggested before, the ability to contain all this information in proximity to the task at hand is a huge benefit. The flexibility to have lists reference each other is also critical as is the ability to include richly formatted content in the lists and attach documents to list items. “Project Management” may benefit from project management software but “managing projects” requires managing information. SharePoint has made that task easy for me!

Managing Complex Projects – Part II

Some of the feedback I received from the first part of this series suggested that complex projects require project management software. I tried to explain why I disagree, but I can’t keep myself below my self-imposed limit of 800 words. Suffice it to say, I think project management software is great if your goal is to manage resources, report status and control budget on a large project that will proceed pretty much according to plan. When the project is smaller, or when the project team is talented and agile and the project plan can change in response to new ideas, project management software gets in the way.

I’ve been managing projects, large and small for over 30 years, and long before “agile” became a buzzword, that was the kind of project I often found myself managing. The key to successful agile projects is to have good and passionate people on your team and to facilitate communication between those people. SharePoint is an ideal platform for managing these projects. Let’s explore a few important requirements of these projects and consider how SharePoint satisfies those requirements:

Everybody Knows Where We’re Going – Each person, regardless of their role in the project, needs to know what the project goal is. If we have an understanding of the master plan, we can adjust our individual tasks to better satisfy the objectives. The SharePoint site we are using as the home base for our systems development project has this kind of information. There are document libraries which hold the rigid procedures and algorithms that describe the system. There’s a library of Excel models which test the implementation of those procedures and algorithms. There’s a list of SQL statements which extract the data from our production database to supply those models. Every document and model is described and every change is described through Version Comments. We’re also using a wiki to design new and modified processes and screens. The wiki is great for this because we can store an image of the screen and functional description and users can explain what does and doesn’t work. Then we can adapt.

Nothing Important is Lost – An agile team makes changes as they work; they see opportunities to save time or to improve operations and they pursue them. At the point of change, the people involved fully understand their decision, but that understanding quickly fades as they move on. We created a Custom List to track our work and we added columns to this list to capture the rationale for changes. Now, in the event that our stroke of genius impacts something down the line, we know what we did and why we did it. What’s great about SharePoint is the ability, as in this case, to modify a list to accommodate new types of information. Parallel to this strength is the ability to create new and different lists. For example, we have a separate Custom List tracking changes we’ve made to database tables. We have a separate list for changes we’ve made to system constants. We have a list where we track implementation progress and test results. This is starting to sound like an iPhone commercial, “yeah, there’s a list for that…” but it’s true and it works.

People Stay Informed and Information Stays in Sync – Not only do people have to know where we are going, they have to know when we’re taking a shortcut and they have to know when we get lost. SharePoint alerts take care of this for us. Establishing alerts removes a communication decision from the team member. No one will ever say “I’m sorry, I didn’t think you would be interested in that…” – if you’re interested, you have already established an alert. Keeping information in sync is difficult when you’re working from documents and lists and spreadsheets but it’s less difficult when they are all stored together. The ability to add columns to document libraries and attach documents to List items add additional ways to keep related items together. Finally, adding to the value of proximity is the ability for these lists to reference each other and, as I’ve talked about earlier, update each other.

One thing I’ve learn in 30 years of managing projects is that project success is most dependent on the people involved. The goal of a project manager should be to support those people not simply report on their progress. SharePoint, due to its robust features and agile nature makes it easy to support your team and gather the information necessary for reporting. There are questions though; does SharePoint scale in support of large projects? Can SharePoint accumulate information from multiple related or unrelated projects? Can we transition from “under construction” to “in use” to “planning for maintenance”? I think the answer to all three questions is “Yes” but I would welcome your thoughts. Please add a comment or shoot me an email. If you want to know why I chose the picture above, or if you want to understand some of my inspiration for managing projects the way I do, read Mob Software: The Erotic Life of Code by Richard P. Gabriel & Ron Goldman.

Document Workshop – Part Two

Last week, I promised to share an example of the collaborative space where proximity rules. I’m going to use the site pictured last week, the site we use to produce our training newsletter. Publishing a newsletter presents some interesting challenges. First, the production is divided between an editor and a person responsible for layout. Second, in the ideal edition, the content is written by multiple authors, some who are new to the task. Finally, the newsletter is produced in Adobe InDesign but contributing authors don’t have access to that software.

If we start our tour in the middle left, we find a contact list. This is the contact information and contribution history of authors and the editorial staff. If you have questions, these are the people to ask. Below that is a task list. We don’t always use this, but when we have multiple authors or complicated articles, we manage those tasks here. When we move to the right side of the page, we start working with digital resources.

Topping the right-side work area is a document library. This is where the working copies of the newsletter are developed. There are folders, yes folders, for draft articles and supporting graphics and images. The folders work in this case for a simple reason. Once a newsletter is produced, the draft articles are disposed of but the graphics may be useful in future issues or, readers may ask us for a copy of a chart or image from a particular edition. Having both sets of items in the same location helps the layout artist do her job more easily, especially since we’re using InDesign. InDesign isn’t SharePoint aware so we’re working ‘old school’, check-out, edit, save and check-in. Discovering new libraries isn’t Adobe’s strong suit so starting in the same location speeds that process along.

Beneath the document library is a custom list we call our ‘Toolbox’. This list is designed to store instructions and, if files are necessary, they are attached. We have a variety of “regular” columns in the newsletter. For each of these, we describe the column, provide tips for writing it and specify the column length. In addition, since the authors don’t have InDesign, we created Word templates with columns, margins and Styles that mimic the InDesign layout. These are stored as an attachment to the list item. Another list item includes the Storyboard we use to plan the layout and the instructions for completing that. Another list item has the instructions for producing the printed copy and the PDF copy as well as the distribution instructions for the PDFs.

At the top of the page is a Discussion part where authors can ask questions and we can debate design issues without starting an email barrage. Under the toolbox is a list of useful Links. Some of these are permanent, some are removed after publication. With each new edition, we start with the essential tools and recent examples close at hand. What happens to the finished copies? They are managed in a different site, once they are published, the production crew doesn’t need them.