Software Project Delivery - 7 Common Pitfalls

Software Delivery Pitfalls


There is much more to know about project management than one can learn from books, training, and certifications.  Some knowledge is acquired through real world experience.  In this blog entry we discuss 7 common project pitfalls that software delivery project managers can experience.

Unskilled/Under Motivated Team

There can be as much as a 10-to-1 productivity ratio between a “great” software developer and an “average” software developer.  If your team members are sub-par you are starting off with a losing hand.  No matter how effective you are at managing a project team poor team members can kill your project.  They deliver product late, implement code with a high defect density, and or do not pay attention to requirements specifications.  You can’t always have a “rock star” team, but if you start out with bad ingredients don’t be surprised if the end result does not live up to your organization’s expectations.

Unrealistic Schedule Expectations

Our world is a fast paced ever changing environment.  Delivery teams, like all other aspects of your organization are expected to evolve and change at a dizzying pace.  Let’s face it, more often than not, your project stakeholders need your project to be implemented yesterday.  It’s good to be agile, nimble, and responsive, but creating and committing to unrealistic schedules does not do anyone any favors.  Be aggressive with your plan, but be realistic.

Not realizing or accounting for non-development tasks

Does your delivery plan include ALL of the tasks necessary to deliver the project? Are you sure?  Don’t make the mistake of including only “development” related tasks in your plan.  The plan should include project related efforts that go beyond the obvious “Design, Code, Test”.  Don’t forget to include necessary tasks like detailed requirements elaboration, requirement feedback cycles, business requirement churn and technical training for team members.  These important tasks should not be excluded from your baseline project schedule.

Shortchanging Requirements Definition

Many new project managers feel that anything that doesn't involve writing code is overhead and is therefore a waste of time. We all know that you want to be responsive and agile with your project stakeholders and that’s good.  Responsiveness is good, developing code, and then re-developing code is bad.  Before coding make sure that you have the requirement details and that they defined to a level where they can be tested.    We are not necessarily talking old-school waterfall model here.  You do not need to know ever feature and functionality of the entire system before coding can begin.  Break your project into logical iterations, gather detailed requirements for iteration #1 then have the team start coding iteration #1 while the requirements team moves on to requirements for iteration #2. Continue this process for all iterations.

Underestimating Testing Effort

Most project managers struggle with estimating and planning the effort required for testing.  This is the most common reason that projects seem to be on schedule until testing is in full swing.  A good rule of thumb is that testing and defect repair should represent about a third of your project delivery effort.  In the days of waterfall testing began when development was complete.  A better approach is to begin testing as features are complete.  If your project budget can’t support this testing effort, at least begin testing at the completion of each functional iteration. If your project doesn't take into account this reality, then you will either deliver late or deliver a product of poor quality.

Scope/Feature Creep

“Requirement adjustments”, “feature requests” and “just one more thing” type changes are not the exception. They are the rule.  As the project progresses, project stakeholders learn more about their needs. They come up with new features and ways of improving existing ones. Don't let these changes drive your plan and your team into the ground.  In most cases, you can’t just say “No”, but you can control how your process and account for these requests.  Gather, analyze, and document the requests. Communicate the impact the changes will have on the plan and collaborate with your project stakeholders to work the features into future releases.   The perfect product is rarely delivered on the first release.  Deliver on your existing commitments, and try to schedule as many of the change requests into a subsequent release.

Throw the delivery plan out the window

Even the best laid plans can run into trouble, but do not abandon process and rigor in managing your project.  No matter how great a performer you are team members will underperform, customers will have change requests, and unforeseen technical issues will arise. How you react to these challenges can make all the difference.  When your project deviates from the plan adjust and evolve the plan.  Don’t abandon it or take “shortcuts”.   Without a realistic updated plan you cannot have open and honest communication with your team or your project stakeholders.

Follow Us

Twitter icon
Facebook icon
LinkedIn icon
Google+ icon

Recent Tweets

Copyright 2014. Level 5 Partners, Inc. Back to Top

Back to Top


Get Our Content Free Via Email

Get original program management office and project management content sent straight to your email inbox for free, and we promise never to share, trade, sell, deliver, reveal, publicize, or market your email address in any way, shape, or form.
* indicates required