Should You Equip the PMO with Netbooks?

Let me answer that right now…NO. However, are they bad? Again, NO. Now that I’ve gotten my feelings off my chest on this, let’s dive in a little further.

Don’t get me wrong, I wholeheartedly approve of netbooks. I’ve purchased two of them in the past four months. They’re great in the right situations and some of those can be PM-related.

First, I feel that there are some misperceptions with netbooks that most people have and need to overcome – I was included in this group at one time:

• The screen is too small. It’s not. It’s small, but unless you’re working heavily on graphics, the size is a plus rather than a minus. I’ve grown tired of the large, widescreen laptops. I’m much happier on my 13” Macbook than I ever was on my cumbersome 15.4” Gateway and I’ve used one of our home netbooks to surf, write a document, etc. and had no problems at all with it’s screen size. Granted, it’s of the 10” variety, not one of the 8” netbooks.
• The CD/DVD drive is critical. I can’t tell you when I last used a CD/DVD drive unless it was to load a CD into iTunes (which I almost never use anyway). I purchase software online and download so I know it’s possible to live without those drives. But, if you must have one, you can purchase an external one and some of the models at Costco actually come with the external drive included. The CD/DVD drive is no longer a necessity…it’s a ‘nice-to-have’ and an ‘almost-never-used’ extra.
• The processing power won’t be there. I don’t see it. I bought two of the the Asus Eee PC netbook. It has the Intel Atom processor which operates at 1.60 GHz and the netbook comes with 1 Gb of DDR2 RAM. Now, they aren’t being used on Photoshop, but for high school and college work and for low-end photo editing, writing, some video editing, etc. the netbooks have done everything we’ve asked of them.
• They are more fragile than a regular notebook. Again, not true or at least I don’t see it. In fact, because they are smaller and easier to carry around, dropping them or hitting on something as you walk by is far less likely. My 15 yr old daughter has gone through two phones in that time period by her netbook doesn’t have a scratch on it and she takes it everywhere.

So at this point, I seem to be a netbook proponent. And I guess I am. However, is it a good idea to equip your entire PMO workforce with netbooks and send them out into the world? I’m not likely to agree with that.

I think it may be a decent concept to have some around for checking out by PMs for travel or if your company has that much money to spend, give each PM one to make traveling easier. But I do not think the netbook is ready to be someone’s only work machine. It’s a good add-on if you have the money to spend, but it’s not ready to be a primary machine. I wouldn’t equip my whole family with netbooks as a replacement for all laptops (and I’d NEVER give up my Macbook), so I know I would not condone making this standard fare for all of your PMO’s workforce.

Requirements are the Lifeblood of the Project

There can be no project without a customer. That customer can be internal, external, your boss, yourself. But there is always a customer…someone the project is being run for – someone is ultimately the end user of the solution that the project implements.

Customers Often Lack Proper Requirements

And with the customer comes requirements. If there were no requirements, there simply could be no project. The problem with requirements is that, as we all know, they are ever changing. Trying to keep a customer from changing their requirements during an engagement is like trying to keep my 15 yr old daughter from sending text messages. And trying to get the customer to document good, solid, detailed requirements prior to the engagement starting is like…well…impossible.

The customer ‘expects’ you to help them extract the necessary requirements. It’s happened to all of us, right? The customer is paying the price for the project so they naturally think they can go into the engagement with just some high-level requirements drawn up by a few SMEs and the rest will just get extracted during Exploration.

What Good Requirements Can Do for a Project

That’s fine – and that is often how it goes. However, what the customer seems to always be unaware of is that by going into an engagement with well-documented, detailed requirements they can usually accomplish the following:

• Significantly reduce or eliminate the need for change orders, thus reducing the overall cost of the project
• Reduced change orders means reduced timeframe for the project meaning it is more likely to be delivered on time without extending the schedule to accommodate changes
• Test cases can be written earlier in the process due to requirements that are not moving around – meaning better test cases and better prep for UAT
• Better end product – if requirements are well understood early on and are not a moving target, it is easier for the delivery team to deploy the solution that the customer really wants which also means less post-deployment work and likely less cost to the customer

These are just a few of the benefits…I know there are more. The bottom-line is that the requirements drive the project. Poor or non-existent requirements mean an extended project, budget overruns, and missed milestones. Solid requirements mean a much greater chance for on time and on budget delivery of a solution the customer wants and needs and ultimately greater customer satisfaction. Of course there are no guarantees…and an Agile approach that allows for requirements to shift and for the project to react can help mitigate the overall impact to the project.

Summary

Many things help drive project success, but requirements are critical. If you head into a project with few or poor requirements, it may be worth the pain and suffering to suggest that the customer go away and draw up more detailed requirements before engaging your team. I’ve done it before – though usually I get the most success and agreement on that approach with internal customers. External customers rarely are willing to put anything on hold. For those customers, you must get out the change order pad and start documenting and estimating. They need to know up front – as soon in the engagement as possible – what it’s going to cost them to have your team extract the detailed requirements for them if that wasn’t priced/estimated as part of the project.

How to Ensure Project Success Every Time

Catchy title but there is no such thing. We all know that. The recent discussions on Agile vs. Waterfall on here (see “Agile Software Development Project vs. Standard Software Development Project” and “Agile vs. Waterfall – More Thoughts”) might make you think differently based on comments by staunch Agile supporters. But we all know that not every project is successful.

What Success Isn’t

First, let’s ask the question….what is project success? How do we define what makes a project successful? Well, we can definitely look at some ways to know for sure that your project has not been successful:

• Customer satisfaction with the engagement is very low
• The project was canceled mid-stream
• The PM or key team members were replaced due to performance or customer issues
• The budget is way out of wack
• The timeline has shifted out of control
• Requirements are still changing frequently deep into the project

What Success Is

These are just 6…the list could be endless. Now let’s look at some signs the project has been successful:

• Customer is happily approving and paying for change orders
• Customer satisfaction is high
• Major project milestones and deliverables are being met and approved without delays
• The project budget is inline with expectations
• Delivery team resources are engaged and no dissention is apparent
• Executive management is getting positive feedback from the customer

Again, this is only 6 – there are many more…though I think it’s easier sometimes to see what’s going wrong then what’s going right….sadly.

What Can Be Done

So, we know we really can’t ensure that every project will be successful every time, as the title of this article seems to suggest. Sorry for the bait and switch. But what steps can the project manager take to ensure that we’re giving it the best chance to succeed? Here’s my take:

• Excellent communication of priorities and expectations to delivery team members
• Cohesive, co-management situation with the customer organization with fast dissemination of any alert or critical information – be honest with the customer
• Reusable and repeatable processes and templates in place in the organization for the PMO or PMs
• Strong PMO in place utilizing knowledge sharing and post-project lessons learned sessions
• Consistent delivery of expected material and information – status reports, updated project budget status, issues/risks lists
• Frequent formal and adhoc communications – delivery team calls, customer status calls, email alerts and updates
• Retention of skilled and necessary project resources – fight for them with executive management, if necessary
• Manage the schedule tightly and make sure it’s in every project member’s hands and up-to-date at all times
• Manage all change closely – scope, potential risks, change orders – don’t let these get out of hand because the project can go south quickly if you do

Summary

Nothing is going to ensure success every time. Picking the right technology, the right software development process, the right vendor, etc. will not ensure success every time. What is definitely in our control is good management of what we have and utilization of the tools we have at hand to ensure everyone is on the same page and working toward the same project goals.

Agile vs. Waterfall – More Thoughts

Ok…I have to do a follow-up to my article “Agile Software Development Project vs. Standard Software Development Project.”  It was only posted a week ago and has already generated 20 comments.  And many have been from Agile supporters who can’t even comprehend a scenario where a ‘standard’ or waterfall approach results in a successful project.

You would think I had just stated that Pete Maravich wasn’t the best ball handler in basketball (which he was) and that Cheap Trick wasn’t the greatest rock band in the world (which they are – and you can buy their new CD “The Latest” from Amazon here …sorry for the plug, I know those guys, I know their families and they are hard-working and still at it – so buy the CD already!).  Ok…where was I?

Oh yes, I was lightheartedly discussing reaction to my Agile vs. Waterfall article from 6/11/09.  I’ve been reading all comments and have responded to many of them.  However, based on the comments that have been coming through, I think I need to actually follow-up that article with this one to further clarify my thoughts, the question, and what I’ve learned so far.

My Agile/Iterative Process Background

Let’s start with the understanding that I’ve never worked in an organization that subscribed to Agile practices of software development or project management.  I was leading an enterprise software re-write project that was utilizing an iterative development process for a large customer in Las Vegas when the company I was working for abruptly shut down.  We were through requirements and ready for development so I was already seeing the benefits, but we weren’t able to complete the process.

My Standard/Waterfall Background

Let’s also acknowledge that I have worked very successfully as a Project Manager for 18 years now – all basically using the waterfall method for software development projects.  Yes, I’ve seen some failures – both in projects I’ve led and in projects colleagues have led.  Some have ended in a fiery death for the project and careers.  But many have been wildly successful – I wouldn’t be here today if that weren’t true.  I’ve led many small and many very large projects using standard waterfall methods that have ended with happy customers, on time deployment and on budget financial status (except, of course, for necessary change orders as a result of customer and project needs).

Being what I consider an intelligent individual as well as an experienced developer, project manager and IT professional, I can make the educated statement that any process that requires continual customer involvement, short sprints that test and rollout a solution every 2-4 weeks, and constant attention to evolving requirements is bound to have frequent success.  The main problem with any waterfall approach is the fact that the project is based on an understanding the requirements are in place correctly at the beginning.  That’s flawed – they are almost never correct or in enough detail when the project kick’s off.  They usually evolve over the course of the project – with more detail and more surprises extracted along the way…unfortunately.  Usually this requires re-work.  Often it requires change orders.  And sometimes it upsets the customer.  All of that is known by everyone and completely understood by this author.

The Scenario…Again

Finally, I’d like to restate my premise for all.  If a software project has well-defined requirements up front with no need for further definition (yes, rarely, if ever happens…I know), and if the customer is continually involved and everything goes smoothly and your project is well staff with the right skill set…then if you used each method to run the project I am assuming that the overall project costs for the waterfall method would be less than with agile.  This would primarily be  because of less testing, overhead, etc. 

I’m only asking for one hypothetical project, not the best way to run a project and not the best method across a portfolio of projects.  Just one perfect project.  Would it be cheaper to do waterfall than agile assuming no re-work, no re-starts, and no issues?  My guess is “yes.”  And that’s what I’m basically hearing in the comments.  Your thoughts?

Agile Software Development Project vs. Standard Software Development Project

I traveled through the Expo portion of the SQE Better Software Development Conference & Expo today.  The slant was definitely toward Agile Software Development.  I had the pleasure of speaking with representatives from QSM, Rally Software, VersionOne, innerworkings, NetObjectives, Software Quality Engineering, and VMC among others. 

I have not personally fully managed a project that utilized Agile or Iterative development processes.  I was leading a project utilizing an iterative development process on an enterprise-wide software re-write, but unfortunately the project never finished as the company I was working for at the time closed down suddenly, thus sending the remainder of the project to a competitor.

The Standard Process

I’d like to analyze the difference between an Agile Software Development Project and what I’ll call a Standard Software Development Project.  To me, the standard software project follows the process that we all grew up with…

• Requirements definition
• Development
• Unit/system testing
• User acceptance testing
• Deployment
• Post-deployment support (break/fix & tech support)

The Agile Process

Agile is much different, often utilizing 2-4 week ‘sprints’ ending in a usable (though not market-ready) product.  As an experienced software developer, software manager, and project manager I can certainly embrace the concept that an iterative process that involves short bursts to turn out a usable product that the customer can interact with greatly reduces the chances of being way off the mark in terms of requirements vs. the end product.  I can logically assume that the end result is lower costs, less re-work, and a final product that is often much closer to what the customer wanted than what is turned out by a decent percentage of ‘standard’ development projects.

My ‘What If’ Scenario

With what I call the ‘standard’ process there is always a strong likelihood that the end product will not be what the end user actually needs.  The risk is great that either the requirements weren’t detailed enough, or development slowly strayed from requirements enough along the way to provide a basically unusable solution after a development cycle that could be a year in length.  The possibility for wasted time and huge re-work is much greater.  With the Agile process, you can never really be farther than 2-4 weeks off the mark.

The Big Question

So, I can understand the fact that over an entire project portfolio, the likelihood of realizing a significant cost savings could be very high…likely IS very high.  Here’s my question:

If we were to take a large software project and run it both ways – standard and Agile – and then let’s assume that both work perfectly…no re-work, no missed requirements, etc.  At the end of each version of the project, what shape would the budget be in? 

My assumption is, that if everything else is equal…meaning it all goes smoothly with either process…then I would tend to believe that the ‘standard’ process would result in less expense and less effort.  Prove me wrong…I want to hear from the readers – especially Agile promoters.  Over the long haul – the entire project portfolio – I can see it being the better way to go in terms of cost due to less re-work.  But in a perfect world – which is a fairy tale, I know – wouldn’t the cost be less with the standard process of running a software project?  I’m not anti-Agile at all, so please don’t read it that way.  I’m just trying to provoke some thought and discussion here.  Now…respond!