Ask most any developer what's the worst part of a software project and mostly likely you'll hear, “data conversion.” And what's most magical when working a project spec? “We're going to start fresh with new data.”
Reflecting back on the year gone by, clean or messy data migration definitely has a huge impact project success as a whole.
What makes the data migration part of a project so hard?
You look at old data on screen, in reports, or with tech specs. That's often all you get to look at before starting, and that's not enough to judge its true quality. You can't fully judge how well its going to work until you do real trials into the new system. And you can't really do that until you have that new system ready.
So here are painfully accumulated tips about data conversion. I'm writing this from the point of view of the “joint planning team”--lessons to both client and consultant/developer. And I'm not going to say which ones I have the most success sticking to. I'm doing this partly as therapy and partly as New Year's resolution. I promise to reread this myself on every new 2010 project.
Data conversion and the project plan
Do as much clean up as possible in the old system. The data will look familiar there, and staff who have to do it will be faster on the old.
Don't wait until the end. Put time in the schedule to for clean-up straight through the planning and configuration of the new. Reflect each decision about the new back to the old. Understand how you will get there and when the route can be opened.
It's often hard to reserve enough time for clean-up. Explore whether you can effectively use volunteers, interns, or temp staff to do routine clean up work instead of taking consultant project time to do it or burdening organizational staff beyond what is reasonable or essential for each side to do.
Data conversion and the budget
Here's a tough one: See if you take data conversion outside of the rest of the project estimate and work it as time and materials. That protects the consultant and focuses program manager attention on only doing as much as is necessary.
The fall-back choice is to allocate a specific, reasonable number of hours, say as a percent of the whole project, and agree that the consultant will do much and as best they can within that block of time, and no more.
Data conversion and "letting go"
A corollary to the last: Consider converting the essential top level stuff—the primary contact lists—and not all the historical details (all donation or membership history, services rendered, etc). The top level lists are often cleaner, easier to check, more essential, and less encumbered with old-to-new data structure changes.
For historical data you really do need, consider adding special new fields to summarize the old. For example, instead of importing an entire “trainings” history, can you live with aggregating “total workshops attended” for each contact? And remembering preferred training topics, how about just tagging the contact with “attended series A workshops” or “workshop B series”? You might be surprised how much headache this saves where the old data turns out not as clean as it now appears on screen.
Data conversion in stages
It frequently makes sense to plan on a data migration way station--a temporary clean-up and check-me database. It could be Excel, Access or something else that has strong query and reporting tools. Maybe all the status categories need to be remapped, or collected from three different current places. Maybe the notes field holds way more than notes and needs analysis
On the other hand, the new system may have fantastic clean up tools available, such as address correction and verification, or deduping. Maybe it specifically has importers for the old donor database you are moving form. Check them on sample data and use them where you can.
What about all the rest of the details of the old? If keeping the old system around does not incur licensing or hosting costs, why not just leave it up, frozen as an archive for historical data. Again, only convert what is really needed.
Data conversion and testing
Count on doing at least one trial conversion for staff to test before the day you go live. Once you have worked that into the plan, it makes sense to do it as soon as a trial version of the new software is up. Let folks test the new software with some real, existing data. It improves the testing and improves the data migration. And make sure you have put time on the calendar for that checking. Discovering gaps six months into a new system, say when quarterly or annual reports first have to run for real, really will mess things up.
Do have a series of benchmark queries to run on old and new system to quickly check results. For example, maybe the count of contacts by status group has to match exactly. Maybe the total dollar value of donations by year will not match 100% for this, that and the other reason. Make an agreement in advance, the new system will vary by as much as 3% earlier than the last two years.
Conversely, agree on a couple representative accounts you will use as a standard base line for checking the conversion. I remember one large scale donor management system with a huge master contact list mostly sparsely populated and just a handful with tons of details. Running overall lists just wouldn't cut it. Every step in the development process had to be run against one particular wealthy donor with a 28-page single spaced personal profile. Each new iteration of the software had to pass muster on him or it was back to the cubicles for us.
Data conversion documentation
Data conversions usually involve a lot of steps. List them out in a shared document and explain what each does. When you have a series of scripts that have to run, number them in order, like “step100_clear main contact table,” “step 200_import from spreadsheet xyz,” “step310_relink contacts table to database X_manual step,” step 315 _import from database x,” “step 400_run dedup query,” “step510_extract priority A people to excel and give to ED to check personally.” By putting that first step in there, you have already set things up for running the conversion process as a whole more than once. Get every step, manual or automated, in there. Consider counting by 10s at least so you insert more steps as you fine tune the overall process.
Use a shared Google doc or some other collaboratively editable document to hold the conversion steps. Even if your steps lean toward the technical, take the time to go through them collaboratively, understand what they mean, and sign off that this is the plan.
Data conversion therapy
Accept that data conversion has a therapeutic component. You can count on the staff person who is most impatient with the old system to miss data and procedures that don't show up exactly the same in the new. Hmm. My Tai Chi sensibility says maybe the framework is more meditation than therapy: it's all about grasping the essence firmly, remaining calm to find the path from the old to the new, and letting go of what you can.
And through it all, be reasonable and patient with each other. This means the organizational lead needs to look at the raw underbelly of the data and appreciate whatever is giving he consultant the most trouble. The consultant needs to sit with users and understand the consequences, workarounds, new ways of doing things if new data doesn't 100% line up with the old.
Data conversion sounds like such a mine field that you might ask, why would anyone ever agree to do it? Well, you often have to, to get the project at all. In addition, I have to say, data conversion does have a creative appeal. Its almost always unique. Unlocking old data is like unraveling a mystery. It requires real detective work. It requires knowledge of multiple systems, which takes time and experience to accumulate. If both sides agree to a reasonable plan, it is possible for all to find satisfaction and joy when the new reports line up with the old.
And speaking of the therapeutic and the meditative, just writing this has been both therapeutic and meditative for me. hope it helps you as well, and best wishes for the New Year.
Here at Idealware, an organization that's all about nonprofit-focused software, we understand that the success or failure of a software project often has far more to do with the implementation than the application. So, in addition to discussing software, we talk a lot about project management. To many of us, it seems like the only thing worse than devoting our scant resources to the task of building and maintaining a complex project plan is living with the result of a project that wasn't planned. While I'm a big a fan as the next guy of PMP-certified, MS Project Ninja masters, and will argue that you need one if your project is to build a new campus or a bridge, I think there are alternate methodologies that can cover us as we roll out our CRMs and web sites, even though I know that these projects that will fail expensively without proper oversight.
The traditional project planning method starts with a Project Manager, who plays a role that fluctuates between implementation guru, data entry clerk and your nagging Mom when you're late for school. The PM, as we'll call her or him, gathers all of the projected dates, people, budget, and materials, then builds the house of cards that we call the plan. The plan will detail how the HR Director will spend 15% of her time on a series of scheduled tasks that, if they slip, will impact the Marketing Coordinator and the Database Manager's tasks and timelines. So the PM has to be able to quickly, intelligently, rewrite the plan when the HR Director is pulled away for a personnel matter, skewering those assumptions.
My take is that this methodology doesn't work in environments like ours, where reduced overhead, high turnover and unanticipated priorities are the norm. We need a less granular methodology; one that will bend easily with our flexible work conditions. Mind you, when you give up the detailed plan, you give up the certainty that every "i" will be dotted, every "t" crossed, and every outcome accomplished on schedule. But it's possible to still keep sight of the important things while sacrificing some of the structural integrity.
First, keep what is critical: clear goals, communication, engagement and feedback. The biggest risk in any project no matter how well planned, is that you'll end up with something that has little relation to what you were trying to get. You need clearly understood goals, shared by all internal and external parties. Each step taken must factor in those goals and be made in light of them. All parties who have a stake in the project should have a role and a voice in the plan, from the CEO to the data entry clerk. And everyone's opinion matters.
Read up on agile project management, a collaborative approach that is more focused on the outcomes than the steps and timeline to get there. Offload the project management by focusing on expectation management. The clearer the participants are about their roles and accountability for their contributions, the less they need to be managed. Take a look at the Cult of Done (their manifesto is at the top of this article). Sound insane? Maybe. More insane than spending thousands of dollars and hours on an over-planned project that never yields results? For some perspective, read The Mythical Man Month (or, at least, this Wikipedia article on it), a book that clearly illustrates how the best laid plans can go horribly wrong.
Finally, my advocacy for less stringent forms of project management should not be read as permission to do it haphazardly. Engagement in and attention to the project can't be minimized. I'm suggesting that we can take a more creative, less traditional approach in environments where the traditional approach might be a bad fit, and for projects that don't require it. There are a lot of judgment calls involved, and the real challenge, as always, is keeping your eye on the goals and the team accountable for delivering them.
I’ve been thinking about task management lately. Seemed like a good thing to reflect on over the long weekend. If you are like me, the biggest problem about task management is just plain old too many. Some weeks I feel like I’m gliding through my lists until a loved one reminds me, I just have too many.
If you have too many tasks, then you need to focus first on having fewer of them. That’s what some systems (philosophies? Self-help psychologies? Emergency medical care?) are all about. Dave Allen's "Getting Things Done" has a lot of popularity in this department. If you haven’t read the book, check it out. Most people probably can’t fully live the GTD way. I personally grant permission to cherry pick from its choicest rules. Things like, if you can deal with something in less than two minutes, do it now. If you can’t, put it where you can find it so you don’t have to clutter your mind with it until you can deal with it. And on from there. Too Much Mail
For many of us, even before we get to our task lists per se, we have to face our email inbox. My inbox is like a tide washing up new tasks every day. I’m not going to tell you exactly how big my inbox is right now. It’s embarrassing. I’m working on it.
I get a lot of help form using the GTDInbox for Firefox + Gmail. GTDInbox adds a life-saving layer of task buttons built on top of Gmail’s labeling. (GTDInbox is independent of Dave Allen, and just carries forward some of the methodology. ) If you use Outlook, the Dave Allen company (www.davidco.com) has a nifty full-featured add-on. And if you use Thunderbird or other mail, Dave A offers an inexpensive PDF guide to adapting GTD manually.
For me, for now, GTDInbox rules. You can find it as a standard free Firefox add-in, and you can learn more at GTDinbox.com. I’m sure a premium version is heading our way, and I suspect a lot of folks will jump for it.
Too Many Projects
After too many tasks, my second biggest problem is having too many projects. Collaborative software commonly used for project management software generally comes with ways of dividing up project tasks. In Basecamp (www.basecamphq.com), you have a simple structure of milestones that give you due-dates, and to-do lists that assign responsibilities for meeting those dates. As I mentioned here recently, the new Open Atrium for Drupal has projects and cases, also in a clear intuitive organization that favors collaborative discussion, blogging, and document management. Microsoft Sharepoint, Central Desktop, Zoho and others also have their equivalent.
These systems are definitely a great thing for getting a team already discussing project goals and needs to now focus in on discrete chunks of work. If you are blessed to not have too many projects, this can also work for your individual daily task management. I use and need these features. Yet for much of what I need to get on top of every day, I find myself getting bogged down in navigating down and up the hierarchy of client-project-milestone-tasks.
For Basecamp at least, there are cool Windows or Mac desktop integration add-ons that simplify the to-do process. See http://basecamphq.com/extras for ideas. Some are even free; some have costs that add up as you add users. I have sporadically used the Project Recon add-in.
Like many people, even if I end up duplicating PM entries, I need to quickly get in, order and prioritize all the things to do today, tomorrow, this week and beyond in one place. I need a task list tool, pure and simple. Sometimes I come back to the idea that the best task list tool is the same small notebooks I carry around all the time. Notes with pen and paper. If you have been at meetings with me, then you have likely seen me with one of those black moleskine notebooks. http://www.moleskines.com/klmb712.html. Compact, rugged, no batteries and low carbon footprint, visual, fun, well-engineered, works in weak wireless area all the rest.
Where the notebook falls short is getting those tasks on your calendar. There is definitely a virtue to coming back to my desk, looking through my notebook entries for the day, and reorganizing them into on-line memos, events and tasks. To be useful, those tasks have to wind up on or close to my calendar. That’s the biggest advantage of a software task list.
Too Many Tasks
Maybe you still use a paper pocket calendar. Maybe you can fit your tasks in the margins of the dates on the calendar, and don't have to share your task list with anyone else. I admire this and recognize that you live a different life than me. Fortunately for me and probably most readers here, there are some amazing good software choices for simple task lists. I’ll mention a three favorites, and hope you will help fill in the gaps with others.
Google tasks: If you use Google calendar, why not use its own task list? The task capability has been recently spruced up to include list categories and dates. For most purposes, will do the trick, and if you have mobile Gmail, you can see them there as well.
Remember the Milk(http://www.rememberthemilk.com/) adds some pretty nifty features. You primarily use it on its web site, which has a simple, uncluttered interface. And you can add your notes and stuff to a task as it comes into play. You can do more visual organizing of your tasks, with a tag cloud, location map and other options you may find soothing as you face a daunting list of things to do.
And lots of cool stuff being done through the RTM API to lets you see your tasks when and where you want. You can also integrate RTM (yes, its adherents have claimed its 3 letter acronym) with your google or Apple iCal calendar. It will send you reminders via email, SMS text, Twitter, or IM, iPhone app, or off-line Google gadget. And if all else fails, you can share your task list with trusted contacts, who will hopefully help you reduce the task load rather than add to them. RTM has enough going for it that I've read blog posts arguing for abandoning more complete project communication systems like Basecamp in favor of just sharing lists with contacts on RTM.
Last I’ll mention Evernote. Evernote has flexible task lists like the others. It is also a polished, modern desktop app that enables pretty slick note taking, both text and web/multimedia clips. If you use your laptop in a lot of meetings, take notes on phone calls, or are constantly clipping articles and multimedia for later reference and writing, evernote has a lot going for it. It syncs an installed Mac or Windows desktop application with an easy, secure web site. Unfortunately, the desktop app will not run on my trusted lightweight Ubuntu netbook, but the web interface is cool enough I might go back to it again.
All three of these are ideal where you do have to manage tons of tasks day in and day out, and your your immediate tasks don’t always line up with a small, tight, hierarchical list of projects. Try them all and see what supports you best.
And having finished this, I get to cross an item off of my task list! Even better, thinking through the choices and casually interviewing a few folks recently about their habits has been therapeutic. Still too many tasks, and yet more confident about the choices in managing them.
I’m trying out Open Atrium. http://openatrium.com/ Now in first beta, Open Atrium from Development Seed consolidates powerful project management features to Drupal in a modern, polished format.
When we first started bearing down on Drupal two years ago, about the first thing we wanted to do manage independent projects on our own www.dbdes.com site. We got reasonably far, with the ability to define clients, projects, tasks and organize blog-like discussion and documents for each. Given the state of the art two years ago in Drupal and our own priorities, we eventually shelved it in favor of a generally positive relationship with Basecamp (http://www.basecamphq.com). Meanwhile, many of our Drupal sites required one or another set of Intranet features, and each one got delivered in customized, one-off ways.
Fast forward to summer 2009, and the Open Atrium project led by the wonderful Development Seed team (http://developmentseed.org/) promises to provide a standard Intranet within a Drupal site. I suspect along the way, it will give Basecamp and its competitors a run for its money. Well, given that Open Atrium is open source, “run for the money” may not be the best way to express the comparison; more about that later.
So what is Open Atrium and what does it have?
Install Open Atrium as easily as Drupal 6 generally, and then get going with it in about 5 minutes. Open Atrium has all the polish now available in Drupal 6-on-the-verge-of-Drupal 7.
Create a group and start adding users to them. If you know Basecamp, a group might correspond to a “project.” As with a Basecamp project, you can have people from more than one company on a project. Drupal fans: Open Atrium groups rely on Drupal’s “Organic Groups” module and start with all that OG power.
From the group dashboard, you see a snapshot of all the recent activity for the group, and each user can customize elements of his/her dashboard.
Each group has its own group blog for discussion with comments and related documents. Anyone who uses project management software these days would probably agree that the blog format works better in a more modern way than older-style web forums or bulletin boards. And it uses the increasing popular "markdown" technique for formatting text. You can assign users with the group to take part in a discussion, with notifications going to the user by email. In the full production release, Open Atrium will also have other familiar forms of messaging.
Each group has its own calendar of events, which aims to exchange in and out with your other calendars. Use the calendar to mark out deadlines and major project events.
Document library, in any upload format, including the ability to compare revisions of documents.
Each group also can have a “shoutbox,” which resembles a private group twitter space. What is a private twitter? We have experimented with Yammer (http://www.yammer.com), which you should check out if you want a cool, free, private twitter for your team. Having a group shoutbox offers the same and part of the whole Open Atrium for that group. This has great potential in itself when it reaches the full release stage.
Case Tracker. In the case tracker, you create projects for your group, which I would say roughly correspond to Basecamp milestones, and then you add cases to them. Cases correspond to to-dos or tasks. The case feature already has the advantage of assigning multiple people to them, having start and end dates associated with each case, setting priority, notification and so on. Basecamp alternatives has features like this, and it’s great to see them in Open Atrium. And each case has full blog like discussion and the ability to attach documents.
This is a very cool start. And I expect Open Atrium to really take off. Within the Drupal community, adding Intranet and collaborative features like these has been part of the big appeal. Open Atrium offers the prospect of being able to do it in a standard way.
Having a complete open source project management alternative is part of the larger discussion about cloud computing and hosted software. We like delegating to 47 Signals (the Basecamp publisher) all the administration of the site for all our concurrent projects. And yes, I do trust having client data secure on Basecamp. Wow, one big thing not to have to worry about!
The Basecamp API allows manipulating of any and all data they store for me. And even without that, I can regularly download all project activity in one XML file. Please note: Not project documents, but everything else. With the help of the wonderful ThickToast add-on from http://www.vb123.com/basecamp/, I can regularly bring Basecamp activity into our internal Access-based billing system.
Yet overall, like our use of any Software-As-A-Service provider, disengaging from Basecamp would be a complicated process. Like moving out of a place you have lived in for a while, lot of stuff to take care of and fit to where you are going. And it does mean counting on some start-up company’s commitment to privacy and security.
Open Atrium allows you to host your stuff wherever you want. All your data is there in accessible MySQL tables, following Drupal standard node format. Like everything else with Drupal, you will have the choice of your own private server; hosting it on any of tons of reliable Internet Service Provider; or -- I suspect -- provided in fully managed SAAS format by Acquia or someone. For Drupal developers, taking part with Development Seed in the development project is a lot more friendly than making suggestions, say, to the Basecamp folks.
What provides more overall peace of mind I will leave as (an interesting) topic for another day.
For sure, Open Atrium is Open Source, downloadable without licensing fees. And those who involved, which I suspect we will, will have a lot of say in how the project evolves. In the first week of release of the beta version of the software, over 10,000 people downloaded it—outstanding for a brand new Open Source project. And the project has close to 2000 twitter followers.
Check it out; I know we will. I am already thinking about which upcoming project to manage from it.
I'm following up on my post suggesting that Wikis should be grabbing a portion of the market from word processors. Wikis are convenient collaborative editing platforms that remove a lot of the legacy awkwardness that traditional editing software brings to writing for the web. Gone are useless print formatting functions like pagination and margins; huge file sizes; and the need to email around multiple versions of the same document.
There are a lot of use cases for Wikis:
We can all thank Wikipedia for bringing the excellent crowd-sourced knowledgebase functionality to broad attention. Closer to home we can see great use of this at the We Are Media Wiki, where NTEN and friends share best practices around social media and nonprofits.
Collaborative authoring is another natural use, illustrated beautifully by the Floss Manuals project.
Project Management and Development are regularly handled by Wikis, such as the Fedora Project
Wikis make great directories for other media, such as Project Gutenburg's catalogue of free E-Books.
Almost any popular Wiki software will support the basic functionality of providing user-editable web pages with some formatting capability and a method (such as "CamelCase") to signify text that should be a link. But Wikis have been exploding with additional functionality that ramps up their suitability for all sorts of tasks:
The Floss Manuals team wrote extensions for the Open Source TWiki platform that track who is working on which section of a book and send out updates.
TWiki, along with Confluence, SocialText and other platforms, include (either natively or via an optional plugin) tabular data -- spreadsheet like pages for tracking lists and numeric information. This can really beef up the value of a Wiki as an Intranet or Project Management application.
TWiki and others include built-in form generators, allowing you to better track information and interact with Wiki users.
And, of course, the more advanced Wikis are building in social networking features. Most Wikis support RSS, allowing you to subscribe to page revisions. But newer platforms are adding status updates and Twitter-like functionality.
Before choosing a Wiki platform, ask yourself some key questions:
Do you need granular security? Advanced Wikis have full-blown user and group-based security and authentication features, much like a standard CMS.
Should the data be stored in a database? It might be useful or even critical for integration with other systems.
Does it belong on a local server, or in the cloud? There are plenty of great hosted Wikis, like PBWorks (formerly PBWiki) and WikiSpaces, in addition to all of the Wikis that you can download and install on your own Server. There are even personal Wikis like TiddlyWiki and ZuluPad. I use a Wiki on my Android phone called WikiNotes for my note-keeping.
Are you already using a Wiki? You might be. Google Docs, with it's revision history feature, may look more like a Word processor, but it's a Wiki at heart.
Usually, we’re all so focused on the good stuff we want to do, it’s hard to step back and consider when and why Information Technology projects go wrong. While success rates vary by project size, company size, project nature and so on, technology researchers at Gartner still figure that about half of corporate technology initiatives fail. Pretty scary, if you aren’t familiar with these statistics.
Luckily, there are folks like Michael Krigsman who pay attention. Michael writes the ZDNet blog on “IT Project Failures,” and you can follow it at http://blogs.zdnet.com/projectfailures.
Michael and Lisbeth Shaw, friends of mine from Boston, founded Asuret (asuret.com) to provide tools and consulting services to increase technology project success rates. With fellow zdnet blogger Paul Greenberg, Michael recently organized a virtual town meeting of technology strategists which I was fortunate enough to take part in. (Check out Paul Greenberg’s book and articles on CRM--customer/contact relationship management--at http://blogs.zdnet.com/crm/ and http://the56group.typepad.com/)
The experience of those in the discussion confirmed Paul’s statistics about corporate CRM projects. The big theme, cultural and collaboration issues predominate over direct technical or formal project management issues as sources of CRM project failure. Implementation of a new system may succeed on its own terms and still fail when users vote with their feet and fail to embrace it. They keep using their private Excel spreadsheets or personal email lists instead of new systems. This is important to think about when day in and day out, we may instead worry about the pace of technology innovation, how hard it is to get the latest and greatest things to work as expected and so on. These are all true, yet its the social and cultural factors which have the highest risk.
Insufficiently involving users from the beginning appears, both in statistics and in experience on the call, as a critical factor when a technically successful project still winds up abandoned or drastically recast. If not involved from the beginning, users won’t bother later on. While this may seem a truism, in my own experience, you may think you are involving users at the right level and to the right degree only to discover months later that you need to go back.
Smaller projects and organizations have limited budgets and limited staff time for concentrated planning. The danger here, which apparently affects large technology projects just as much, is that management focuses on choosing features and functions and selecting a vendor ahead of an effective, well understood, and widely accepted strategy.
Those that know me, know I like to consider where for profit and nonprofit technology planning issues converge and can benefit from each other and where they diverge. In the nonprofit world, we may see technology implementations responding to tight grant funding cycles and too quickly focusing in on formal RFP processes. These pressures may be the particular reason behind inadequate work on culture and strategy despite nonprofit emphasis on them in general.
The Asuret town hall provided a great opportunity to step back and consider these issues with folks from around the country working on pretty diverse projects. To follow the discussion on your own, check out the blogs mentioned above and resources on the Asuret site, which I hope to comment on in a follow up article.
I'm a big fan of maxims, adages, anything that sums up an important, and possibly complex point in a sentence that can convey, if not the whole point, at least a conversation starter. The main challenge for a technology manager is communication, particularly with those who are uninterested and/or threatened by technological terms. I live and breathe this stuff, but I understand that I'm in the ten percent, the ten percent of people who like and are completely comfortable with technology. The rest of the world ranges from averse to highly competent, but not gaga over it all, like I am. Remembering that, and approaching each project and decision with that in mind, has helped me accomplish significant things for people who aren't necessarily bought in to all of my ideas on first listen.
My current favorite maxim is Users own functionality, techies own platforms. This encompasses a couple of key concepts. First, technology isn't owned by IT or the people they serve; it's owned by both those who install it and those who use it. Therefore, technology can't be evaluated and planned for solely by one group or another. But I've seen lots of cases of both - IT rolling out a fundraising database or point of sale system with no input from the people who will base their revenue goals on the systems' capabilities; and staff rolling out equally complex systems with little or no IT guidance. Both situations are likely to be a big waste of funds and effort. Second, the breakdown is clear - IT might be wowed by the cool, Ajaxy interface on that web app, but if it doesn't have the reporting capabilities that the users need, they might be better served by something less flashy. That's for the users to decide. But IT will have a better read on how sound a database structure is for querying and reporting, or what will integrate successfully with other key systems. So IT should have sway over the technologies used, to a large extent.
If you build it, they won't come is another favorite. Unlike some cinematic baseball greats, techies can't build huge systems in anticipation of user's needs and expect them to be adopted, no matter how great the systems are. Clearly identified needs and ample amounts of input and involvement are required for home-grown system development. At my job, I am pushing agile development, which includes user testing and input from early on in development. This means that I'm teaching my staff how to let go a bit, and be more open to feedback, as I'm teaching the non-techie staff how to evaluate functionality in unfinished, and possibly somewhat ugly systems. It's not as much training as it is imploring all parties to have some faith in each other.
In business communications, you haven't said anything until you've said it three times in three different mediums. This one was taught to me by one of my greatest mentors, an ED at a commercial law firm that I worked at in the 90's. It boils down to the terser rule of thumb: Assume that they haven't read your email. The biggest mistake that we all make is thinking that we've made our intentions and priorities clear by sending a memo or an all staff email. The truly important initiatives that you're pushing through should be reiterated and the message diversified, to reach people who may not respond to your favorite medium. And, as Paul has well-pointed out, at least one of those mediums should be verbal, and hopefully in the same room.
What are the maxims that you manage and survive by? Leave your best ones in the comments.
Back in September, Peter Campbell kicked off a discussion about project management in this space. I wanted to pick up the thread by focusing in on Basecamp. Among project management-related tools, Basecamp has the buzz. It is quite common when we start a new project, that someone from the team involved will have used it and know their way around it.
The company 37Signals offers Basecamp as a pay as you go hosted service. On their web site, 37Signals tags Basecamp, “Get projects done.” Searching Google for “Basecamp ‘project management’” yields 227,000 hits this morning. All that said, it is a mistake to consider Basecamp a project management system. It is much better to think of it as a communication tool that supports project management.
Interestingly, the 37Signals tagline expands to “Basecamp is the smarter, easier, more elegant way to collaborate on your internal and client projects.” Facilitating collaboration is definitely Basecamp’s strength. As a standard practice for our web and other projects, we store project documents (tracking revisions); set major project dates (milestones); track tasks that follow from those milestones; collaboratively edit and design documents; and above all, as a way to have easy, lively blog-like discussions of project issues. You can follow projects messaging via email or subscribe to an RSS feed.
There is a lot you can do with these tools to keep a project moving ahead and keep a whole team, typically including client staff and consultants. From a formal project management point of view, however, you may miss some things or find what’s there incomplete:
You can’t assign dates to individual tasks (only to entire task lists associated with a milestone). This is perhaps the biggest grievance on the Basecamp forums features wanted list.
You also can’t prioritize tasks or assign more than one person to them. These things mean that you can’t really use the Todo lists as an issue or “bug” tracker.
You can’t create Gantt charts or other formal project management diagrams.
You can create templates for individual todo lists, but you can’t template a whole project. So, we have a todo list template for our steps in a configuring a new Drupal install, but not a template for everything that has to happen from design to go live.
You can track time spent on tasks, but you can’t bill from that time. There are add-ons that help with this.
It is easy to maintain multiple projects with multiple client teams and keep them separate and secure, but you can’t assign project-level administrators. All administrative roles are global to all projects.
Somewhat different: the collaborative note pages (“writeboards”) use a wiki like mark-up language. Most folks would probably refer a standard editor.
Basecamp alone doesn’t have group chat, though you can add it in using 37Signals’ “Campfire.” This allows twitter-like project-based discussion.
Despite these gaps, Basecamp makes a lot of sense when your style of project management emphasizes collaboration. This is particularly so where you need to have collaborative teams including both client staff and outside designers, strategists, developers, which is typical for us. Further, I find myself often in the situation of convening teams that include folks thrust in the position of managing software or web projects for the first time. They have the budget, they have the goals, they represent users with needs, but they aren’t used to what happens next.
Basecamp is in the space as other systems we have tried, including Central Desktop, Zoho Projects, Active Collab, and, yes, our own Drupal-based imitation of some of the features. My thoughts here to some degree apply to all of them, even where some of these have some of the features not (yet) in Basecamp. Emphasizing what we called the client-side coordination of project management, we have found Basecamp’s well-engineered, intuitive, Web 2.0-ish, framework a plus.
Basecamp presents the most essential features for collaborative, iterative, even agile development in an appealing, less techy, less threatening way. It is a compromise, but using things that have more of a full project management mold may produce a drop off in team us. We find greater fall back on just emailing the project manager and expecting him/her to repost messages.
In the Basecamp forums, users express a lot of frustration with 37Signals nonchalance about some of the feature requests mentioned above. It has to be said that they do regularly add features. In the last year or so, they added the ability to response to emailed messages from within your email. They added discussion threads on individual tasks (todo’s). These and some other functional and usability improvements have made a difference. When I read some of the frustration and even anger at 37Signals (ok, see http://www.whybasecampsux.org), I also think about what which of the front line features, including ones we want, might tip things back toward less team participation. If individual tasks had space for due dates, priorities, and multiple team members, would that discourage the client staff from quickly easily throwing things onto lists for everyone to process?
In other words, it’s a trade off.
For those out there using Basecamp, here are some of the things we have found that make a difference:
Show people in person how to use it as part of a planning meeting. Don’t rely on just adding people and sending a message.
Although you can’t “clone” a project or have a project template, you can create todo list templates and these can really help frame standard approaches in your project streams.
Continue to monitor regular email, copy messages into Basecamp and respond there, and don’t make a big deal about it. Over time, folks will likely grasp the advantages of using the system and drift over.
Make sure you choose everyone’s best email address.
Use external links to incorporate external tools that might have your higher end PM functions. Create a project note (“writeboard”) with web links to google docs or spreadsheets, hosted project diagrams, wiki pages, issue tracker, code repository, or resources from other systems you use. This keeps everything centralized.
Check out the add-ins to Basecamp. There are both free scripts (for example, see these cool Firefox scripts for basecamp: http://userscripts.org/scripts/search?q=basecamp) as well as paid resources. (http://www.basecamphq.com/extras) For example, one I like that is cool and inexpensive is ThickToast from vb123.com. It allows you to take the standard XML export of your project data and bring it into an Access or SQL server database for further analysis or integration. There are also tools to integrate with popular products for time tracking, SVN code repository, billing and more.
So, bottom line for us has been, get past the idea that adopting Basecamp, or other such communication software, will give you a complete project management system. Instead focus on its use as a tool to support collaborative styles within a project management framework.
It seems like every month or two, I happen across a forum thread about project management tools. What works? Can you do it with a wiki? Are they necessary at all? Often, there are a slew of recommendations (Basecamp, Central Desktop, MS Project) accompanied by some heartfelt recommendations to stay away from all of them. All of these recommendations are correct, and incorrect.
Project software naysayers make a very apt point: Tools won't plan a project for you. If you think that buying and setting up the tool is all that you need to do to successfully complete a complex project, you're probably doomed to fail. So what are the things that will truly facilitate a project-oriented approach, regardless of tools?
Healthy Communication. The team on the project has to be comfortably and consistently engaged in project status and decisions
Accountability. Team members need to know what their roles are, what deliverables they're accountable for and when, and deliver them.
Clarity, Oversight and Buy-In. Executives, Boards, Backers all have to be completely behind the project and the implementation team.
With that in place, Project Management tools can facilitate and streamline things, and the proper tools will be the ones that best address the complexity of the project, the make-up of the team, and the culture of the team and organization.
Traditional Project Management applications, exemplified by MS Project, tie your project schedule and resources together, applying resource percentages to timeline tasks. So, if your CEO is involved in promoting the plan and acting as a high level sponsor, then she will be assigned, perhaps, as five percent of the project's total resources, and her five percent will be sub-allocated to the tasks that she is assigned to. They track dependencies, and allow you to shift a whole schedule based on the delay of one piece of the plan. If task 37 is "order widget" and that order is delayed, then all actions that depend on deployment of the widget can be rescheduled with a drag and drop action. This is all very powerful, but there is a significant cost to defiing the plan, initially inputting it, and then maintaining the information. There's a simple rule of thumb to apply: If your project requires this level of tracking, then it requires a full-time Project Manager to track it. If your budget doesn't support that, as is often the case, then you shouldn't even try to use a tool this complex. It will only waste your time.
Without a dedicated Project Manager, the goal is to find tools that will enhance communication; keep team members aware of deadlines and milestones; report clearly on project status; and provide graphical and summary reporting to stakeholders. If your team is spread out geographically, or comprised of people both inside and outside of your organization, such as consultants and vendors, all the better if the tool is web-based. Centralized plan, calendar, and contacts are a given. Online forums can be useful if your culture supports it. Most people aren't big on online discussions outside of email, so you shouldn't put up a forum if it won't be used by all members. The key is to provide a big schedule that drills down to task lists, and maintain a constant record of task status and potential impacts on the overall plan. Gantt Charts allow you to note key dependencies - actions that must be completed before other actions can begin -- and provide a visual reporting tool that is clear and readable for your constituents, from the project sponsors to the public. Basecamp, Central Desktop, and a slue of web-based options provide these components.
If this is still overkill - the project isn't that complex, or the team is too small and constricted to learn and manage the tools, then scale down even further. Make good use of the task list and calendar functions that your email system provides, and put up a wiki to facilitate project-related communication.
What makes this topic so popular is that there is no such thing as a one size fits all answer, and the quick answer ("Use Project") can be deadly for all but the most complex projects. Understand your goals, understand your team, and choose tools that support them.
Subscribe through Feedburner