Monthly Archives: April 2014

Debating Proper Project Management Discipline

I just had a fun, spirited debate on Twitter about the definition of a project. It started when a friend of mine tweeted this:

Now, my team at Legal Services Corporation recently finished a project (at least, that’s what I call it) to redesign the Find Legal Aid lookup on our website.  I blogged about that effort, which was kickstarted by the DC Legal Hackers, on LSC’s tech blog.  A few things about this:

  • There was no deadline.
  • It was something that we could have outsourced completely, but we wanted to learn the underlying technologies.
  • It was low priority, and my lead developer had a lot of more critical, time-sensitive  projects on his plate.

So we didn’t set a deadline. We pitched the project to management with clear goals (a charter).  After the initial development was done at the DC Legal Hacker’s first hackathon, we identified the four person team that would work on it internally. We reported on it weekly, during our project review.  And we rolled it out when it was finished.

On seeing Norman’s tweet, I challenged the notion that a deadline is a required element of a project. Mind you, many agile programmers work with the bias that iterating until it’s done correctly is more important than meeting a deadline. I doubt that they can actually sell that to their internal or paying clients often, of course.

So I threw my two cents in:

— Peter Campbell (@peterscampbell) April 24, 2014

which brought this reply from someone that I assume is, unlike me, a certified Project Manager, and therefore better versed and disciplined in the best practices:


So, here I am, coming off of a highly successful development and rollout of our little webapp, being told that it wasn’t a valid project.  The entire tweetstream is copied below, but here are the points that I want to make that go a bit beyond Twitter’s 140 requirement.

  • The Project Management Institute (PMI) awards Project Management Professional (PMP) certification to those who complete the requisite hours managing projects and pass the test. I’ve completed their requisite hours, and I’ve taken most of the test prep classes, but I’ve never gotten around to taking the test. So I agree with Rebel that their definition of a project requires a deadline. But I don’t agree with their definition.
  • As with many certifications, what you have to say to pass the test is not always what is going to work in the real world. My first career was working as a cook/sous chef, which I did through most of my very late teens and twenties.  As with technology, I was mostly self-taught. I’ll never forget one day, when working in a French restaurant in Cambridge, Mass., a fresh graduate of the Culinary Institute of America came on board. He didn’t last his first night on the job.  This guy could make some wonderful, complex recipes, but he was overwhelmed when he hit 15 to 20 orders on the wheel. I get the PMI reasoning, but I’ve adapted it over the years in my nonprofit environments where we don’t have the staff or budget to do things to the letter.
  • I absolutely value the governance of a project management discipline.  I firmly believe that you need to recognize targets and milestones if you want to push forward. My tolerance for “no deadline” is in rare cases like the one above. In particular, I need to have work schedules so that large projects don’t end up piling on top of each other.
  • But the trick to successfully getting a lot of things done well in what we call “a constrained resource environment” (e.g. any nonprofit and most of everything else) is to not let the governance get in the way of getting things done. So I take or leave parts of it, being more formal when there’s more at stake and absolutely informal when it doesn’t threaten our outcomes.

I might get that PMP certification someday, although, at this point, it might be when I retire.  But, with a few exceptions, I have a good track record of overseeing some great accomplishments in my career, and I expect that to continue until the day that I can retire.  And I’ll do it by applying appropriate standards and bucking them when they get in the way of the end goal.

Here’s the tweetstream:

 

Three Ways To Make Sure that Your Next Big Software Project Is A Success

This post also appeared on the Cloud for Good Blog in April of 2014.

Buying a new fundraising CRM or replacing your finance and HR systems are big investments with critical outcomes. These are the types of projects can have a huge impact on your ability to accomplish your mission. Poorly planned, chosen and deployed, they will do the opposite. If you’re grasping for a cautionary tale, just look at the recent Healthcare.gov rollout, or the worse related stories in Maryland and Oregon. But successful implementations happen every day as well, they just don’t grab as many headlines.

How can you make sure that big software projects succeed?  Here are three recommendations:

1. Know what you need

All too often, the decision to replace a system is based more on frustrations with your current system than identified improvements that a new system might bring.  And, far too often, those frustrations aren’t really based on the capabilities of your existing system, but, instead, on the way that it was configured.  Modern software is highly configurable.  In nonprofit environments, where administrative staffing is low and people are juggling multiple priorities, the proper investment in that configuration is sometimes skipped. It’s important that you take the time to thoroughly catalogue your current processes and goals; clearly identify your reporting needs; and establish your core requirements before you embark for this sort of project.

Technology automates processes. If you automate bad processes, you get bad technology.  So making an investment in business process mapping, and taking the time to streamline and enhance the way you work with information today will insure that you know what your new system should be doing for you as you configure it.

2. Be prepared to change the way you do things

Ideally, you’ll invest in software that does exactly what you want it to do for you. In reality, there will be limitations in the way that the software was programmed, or the way that it has to be configured in order to integrate with your other applications, that will be out of sync with your preferences. Software doesn’t have a mind of it’s own; instead, it inherits the assumptions and biases of the developers that created it. They might assume, for instance, that you collect donations from individuals and have no need to recognize households in your system. Or they might assume that your average employee turnover is less than 20%, whereas, at a workforce development agency that hires its clients, 50% is more on the mark.  If the best system you can find suffers from some of these limitations,. you will have to either work around them, or buy the second best system, if it requires fewer workarounds, because you do want to minimize them.

Regardless, you’ll want to understand the underlying assumptions in the application and have a strategy for working around them. Some companies will go so far as to commission or design their own systems (commonly called “build” vs “buy”), but you need to weigh the cost of having a supported system vs. a homegrown one, because, unless what you do is truly unique, those will not be worthwhile trade-offs.

3. Hire a consultant for their expertise and compatibility, not their billing rate

We all want to get these projects done for as little money as possible. So there’s a tendency to hire consultants based on the lowest bid. I’d caution against this. major system configuration projects are generally open-ended — determining the exact configuration and number of hours that it will take to get there before the project starts is akin to inviting the whole city to a dinner party and determining the number of plates that you’ll require before anyone RSVPs. So you want to work with consultants who are very efficient at their work, and very conversant with your needs. What you don’t want to do is hand your project to a consultant who doesn’t really understand your requirements, but has their own idea as to how it should be done.  You could well be left with a system that met the budget, but not your needs, or one that exceeded the budget while being reworked to satisfy your requirements. A good consultant will work closely with you.  they’ll spend more time meeting with staff to learn about your needs then they will setting up the project, but they’ll set it up quickly and correctly based on their thorough understanding of your goals and needs. The hourly rate might be double the low bid, but the total cost could be equivalent, resulting in a usable system that will compensate for the initial dollar outlay all that much faster.

Here are slides that I developed for a talk/discussion on creating Requests for Proposals that vendors will appreciate at the recent Nonprofit Technology Conference.  These include some key strategies for making sure that you hire the right person or firm.

In conclusion, how you go about a software project has far more to do with how you conduct your business than it does with the actual technology.  Make sure that you’re investing wisely by taking the time to understand your needs, know where you can compromise, and hire the best partners.