Employers often favor candidates who already have real-world execution experience. That leaves many capable professionals stuck trying to break into a field that increasingly expects them to already know how to operate inside it.
Thinking about volunteering? A longtime practitioner reflects on her 33-year journey that began after attending her first conference in 1992. Through her many roles, she gained invaluable skills, friendships, and opportunities, and encourages others to make a meaningful impact.
How much do you challenge the directive? If project managers are always going to go along with what they are asked or told to do, then there really isn’t a lot of point in them being there.
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
Maintenance releases
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.
Release 2.0 -> March
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.
Release 2.0 -> March
Release 2.1 -> June
Release 2.2 -> September
Release 3.0 -> December
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.
Release 2.0.1 -> April
Release 2.0.2 -> June
Release 2.1.1 -> July
Release 2.1.2 -> September
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:
Release 2.0 -> March
Release 2.0.1 -> April
Release 2.0.2 -> June
Release 2.1 -> June
Release 2.1.1 -> July
Release 2.1.2 -> September
Release 2.2 -> September
Release 3.0 -> December
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.
ADVERTISEMENTS
"Words are, of course, the most powerful drug used by mankind."
