Tag Archives: agile

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:

 

The Cults That Get Things Done

This post was originally published on the Idealware Blog in December of 2009.

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.