       |
||||||||||||||||||||||||||||||||||||
The Separation of Church and State |
||||||||||||||||||||||||||||||||||||
|
Home > Articles >
When start-ups roll out the first release of their software, they typically have one thing in mind--quantity. No software company produces flawless products, but start-ups do have a reputation for releasing lower quality software. This weakness might initially be tolerated if you offer a unique solution, but at some point in time, you will need to raise the quality bar. That point typically occurs shortly after your first customer uses your product in a live environment.
Once your customer is in production, he will demand significant quality improvements. Not only will he expect you to fix defects discovered during trial, but he will also demand that you patch major issues revealed for the first time in production. What’s the solution?
The Project Mangler Approach
Many Project Manglers have a very simple solution to the quality problem described above. Set some tough standards, rigorously test every release and do not ship a product unless it meets or exceeds your hard-hitting quality metrics. Generally speaking, this approach is very impractical.
If your solution is still in its early years, then it’s a safe bet that there are more features on your product roadmap than in your actual software. That being said, although customers will want better quality, they’re also going to demand that you deliver the next set of features “yesterday”. Since you can’t deliver both quality and quantity at a record pace, there’s only one option. Treat quality and quantity separately.
The Separation of Church and State
In order to deliver both quantity and quality, you need to manage two types of releases, each with their own philosophy.
Major & Minor Releases
If you currently have a project manager in your organization, you most likely already publish dates for your next major or minor release.
That’s a great starting point, but don’t stop here. If your customers can’t see beyond the very next release, they will try to squeeze as many features enhancements and bug fixes in 2.0 as possible. Instead, remind your customers that there will be other releases in the very near future by publishing your entire portfolio.
For best effectiveness, issue a product roadmap along with your schedule to elaborate on which additional feature is included in each “bucket” (e.g. 2.0, 2.1, 2.2 or 3.0).
Maintenance Releases
The major and minor releases deal mostly with quantity issues. Although you’ll typically find a fair amount of bug fixes in any major/minor release, they’re really intended to deliver incremental functionality as per your product roadmap.
To significantly improve the quality of your product while aggressively delivering new functionality, add maintenance releases or “patches” to your overall portfolio schedule.
Most start-ups are very reactive when it comes to patches. They typically wait for a customer to kick and scream before agreeing to build a patch. This reactive management style causes friction between the customer and your company. More importantly, it forces you to evaluate your entire portfolio and determine how you can juggle resources to deliver an unexpected maintenance release without impacting the dates of your other projects.
Putting It All Together
When put together, your portfolio for the next calendar year would look like the following:
While this model is sensible (I’ve used it with great success in the past), you need to intelligently customize the release cadence based on your specific industry and resource profile, a topic explored in further detail in “Confusing Conventions“.
You also want to determine a strategy for phasing out certain releases. For example, you might decide to release one or two additional 2.0.x patches throughout the year, but probably do not want to keep issuing patches on the 2.0.x stream when you have a generally available 5.x product.
The separation of church (major/minor releases) and state (maintenance or patch releases) is an effective way of delivering both quantity and quality software. However, I’m not recommending that you ship low-quality major and minor releases. I’m also not advocating that you never ever include a new feature in a patch or maintenance release. Instead of interpreting this advice as a quantity versus quality approach, think of it as quantity and quality where major/minor releases include mostly new features while maintenance releases focus almost solely on defect fixes.
Luc K. Richard is the editor of The Project Mangler, a Web site dedicated to providing project managers of all levels with practical, hands-on advice. He invites you to visit www.projectmangler.com for more project management articles, tools and tips.
sponsored announcements and special offers
Learn how IT can better guide its strategic investments and operational resource allocation throughout the service lifecycle. With Service Portfolio Management, IT investments and resources are translated into things the business cares about – services. Download the white paper Service Portfolio Management: Manage IT For Business Value.
Don't re-invent the wheel! Why divert resources to developing business intelligence and analytics functionality when partnering results in improved productivity and more innovation? Check out this IDC white paper from SAP to see why partnering with an established BI vendor presents a compelling economic case.
Register Today and Save 15%!
Register now for a webinar on March 23rd: Looking for a Project and Portfolio Mgmt software?
|
 sponsors
vendor offers
vendor events
| ||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||
