ellipsis flag icon-blogicon-check icon-comments icon-email icon-error icon-facebook icon-follow-comment icon-googleicon-hamburger icon-imedia-blog icon-imediaicon-instagramicon-left-arrow icon-linked-in icon-linked icon-linkedin icon-multi-page-view icon-person icon-print icon-right-arrow icon-save icon-searchicon-share-arrow icon-single-page-view icon-tag icon-twitter icon-unfollow icon-upload icon-valid icon-video-play icon-views icon-website icon-youtubelogo-imedia-white logo-imedia logo-mediaWhite review-star thumbs_down thumbs_up

Why you should use Agile for project management

Why you should use Agile for project management Mike Vitale
Back in 2000, I was a young project manager for a webcasting company. The industry was brand new with little to no process. Project timelines and costs were extremely difficult to control and it caused lots of frustration. My management team decided the best solution was a brand new customer relationship management portal or "CRM."   This software was going to fix everything.  All the steps in our difficult to define process would be detailed from start to finish. A software company was contracted to build the CRM with a delivery date of four months. The final price tag had lots of zeroes behind it.

Several unexplained delays and nine months later, our entire department was called into a conference room where the software vendor's product manager was unveiling the new CRM. I ran down the hall, propped my feet up on the conference room table and popped open a free soda with a feeling of great anticipation.  I was handed a  nice, neat three-ring binder with dozens of detailed color print outs explaining the software. Our frustration looked to be over!  Our prayers were about to be answered!

The next 60 minutes were overwhelmingly cringe worthy.  Not only did the product manager repeatedly find errors during the demo, but the software itself was terrible. It was as if the program was designed by a martian who was given a five-minute explanation of our business by someone who didn't work for the company.  Eventually, the demo went so poorly that it just awkwardly ended with the product manager furiously AOL instant messaging a far-off developer. As I tiptoed from the room, my mind could not comprehend how this turned out so badly. The vendor had a dedicated project manager. They had dedicated developers. Someone even spent a lot of time detailing the final, terrible package.  They had plenty of time and  money, but completely missed the mark.  Ultimately, the software was shelved and never released. I have no idea if my company got its money back, but I highly doubt it. What went wrong?

Let's back up for a second. I've practiced traditional project management for many years, including what's commonly known as the Waterfall model. To boil this process down, it's a series of steps project managers follow to get from an initial idea through a completed project.  At the highest level, you have the following project phases:

  • Initiation

  • Planning and design

  • Project execution

  • Monitoring and controlling

  • Closing

Within these phases are additional procedures that guide you through the steps of any successful project. If you are a PMP or CAPM these steps are emblazoned in your mind. Over the years, I have occasionally bent the traditional steps wherever I thought they were clouding my own project team's focus. Sometimes team members are more concerned with the specific project phase details than keeping focus on the end goal. You'll find different definitions of what a project's end goal is, but I'll give you mine, because it's very simple.  The goal of any project is to create an end product that clients and stakeholders are happy with, is easily used and maintained over the long-term and is produced in a cost-efficient manner. (If you work in a for-profit business, you must tack on the requirement for a healthy profit margin.)

Every project manager knows the scope always changes. No matter how well you've planned, no matter what the client has already agreed to (often in writing!), something at some point will change.  The further into the project you are, especially using a pure Waterfall model, the worse off it's going to be. Scope changes are a threat to the end goal. No matter how much we wish it were different, a client who's unhappy with a project because a late scope change could not be accommodated, is a failure.  Keeping team members focused on the end goal means keeping them working (quickly and efficiently) on what's most important.  A team member spending all of their time writing detailed documentation that will likely change ten times in the life of a project is not as important as making sure your client agrees with what ends up IN the documentation. If  you spend more time arguing with your client about what they agreed to in the initial contract versus actually working on the project, you are failing.  We need to have a full understanding of what the client wants and there's no better way than frequently over-communicating.

Finding ways to better handle scope creep, while still delivering a solid product, became a primary focus a long time ago.  A few years back, while describing to a friend what I thought to be my unorthodox style, he told me it sounded a little like Agile.  I expertly answered with "Huh? What?" As it turned out, in early 2001, not too long after my colleagues and I were finished quietly laughing over our CRM debacle, a group of highly experienced project managers met to find an alternative to the traditional PM model. What came out of this meeting is a work simply titled the Agile Manifesto.  In addition to the 12 principles of Agile, the manifesto is as follows:
Agile Manifesto

If you just read this and thought "Hey, this seems like common sense?," I can assure you it's not.  In so many companies, especially those with layers of bureaucracy, employees can't see the forest for the trees. Team members do not talk to each other, and accomplishments are measured by whether an individual project step was completed correctly with little to no understanding of the overall project's success. We have a joke in my office about an assistant basketball coach who loses the game, but is very excited in the loser's locker room because the team saved all their time outs!   This is just one of the problems Agile looks to address.

So, take one more trip with me all the way back to the year 2000. (We'll wave hello to my worthless stock options while we're there.). What did our CRM software provider do wrong? In this example, my colleagues and I were the end client.  However, we were never called, emailed or polled for any information on what was needed or how the end product should work. We never saw a beta version, prototype, mock-up or even an email explaining how the product would work. The vendor gathered incomplete requirements and ran with the project all the way through a blown budget and timeline.  But hey, the documentation and the binders looked great!

Before we let them off the hook, this was obviously also a failure of my management team.  However, if the vendor had worked more closely with their end clients, delivered frequent iterations of the product for testing and created a process loop for quick updates and retesting, it would've been a different story. I'm in no way dismissing traditional project management. In fact, I'm a strong supporter of blending both traditional and Agile principles to adapt to any environment you find yourself in.  Above all, no matter what happens, make sure you keep all of your team members focused on the end goal.

Mike has been with TalkPoint since its inception and brings over 12 years of experience in webcasting technology, specifically in production and technology service, to the company. Prior to TalkPoint, Mike directed production services at Williams...

View full biography


to leave comments.