If you have worked in or with the software industry at all, you have lived through some dramatic delays in product development. For instance, Product Guernsey, originally announced last year, was due in January. It’s now the beginning of June, and it’s announced that the product, now called Providence, won’t be out until September. Or your last major release was supposed to take nine months. A year later, it won’t be out for another nine, so technically the team has worked for a year but it’s twelve months late.
In a business environment where companies are expected to run like clockwork, and planning and efficiency are prized, this doesn’t make your company look good. And people in all industries, including the software industry, are becoming less tolerant of this kind of slipshod scheduling.
If Product Management serves no other purpose, it serves to feed requests for new capabilities to Development and to structure the release of those capabilities. A Product Manager can be invaluable in helping your company be more successful at selecting, committing to, and meeting development (and consequently release) dates.
Read on below for guidance on how to commit to specific product release dates and meet them.
[private]
UK Product Marketing Forum
Are you located in the UK? The Product Marketing Forum meets in the London area (in Reading) to discuss issues related to Product Management and Marketing in high tech companies. The next meeting is Wednesday, June 29. For more info, check out their site at:
- http://www.ukpmf.org.uk/
It’s Like a Cult
In software development departments, the desire to not commit to, let alone meet, specific dates has an almost cult-like following. There’s almost a perverse pride in not meeting dates. This stems from two things. First, technical people who have experience with coding work know that it can be very hard to come up with an accurate estimate of the time it will take to develop something. And if a feature or capability has any dependencies, it becomes even harder to guarantee completion within a specified timeframe, unless you plan for it to take four times longer than you actually expect, in which case the project doesn’t seem worth the effort.
Second, virtually all developers have lived through the very unpleasant experience of carefully designing, defining and planning out work, then committing to certain dates, only to have Marketing or Sales add to the scope of the project while expecting the work to be finished by the original dates. After a stressful home stretch of late nights, weekend work, even work over the holidays, only to have the completed work languish while other parts of the organization take their time to release it as promised, developers don’t want to get burned again.
This means that if you want to move an organization towards committing to fixed release dates, you are dealing not only with the more basic technical problems, but also with a complicated psychological, cultural, and political issue. If you don’t sell the soft benefits of fixed dates, you have a long, uphill climb, unless you get the absolute backing of top management.
But remember that top managers often came out of a development career, and have lived the experience of being conned into working over the holidays for nothing.
Be Prepared to Make Sacrifices
You can commit to a set list of capabilities, or commit to releasing your software on a specific date, but not both. Therefore, if you commit to specific dates, and want to stick to them, you have to be prepared to not allow Sales, Marketing, or the even the President of the Universe to add features after all the work has been planned and scheduled. This is vital to the success of setting fixed dates.
You aren’t really prevented from adding new features in mid-stream, as long as there’s time remaining to complete them. But you add features only at the expense of others which you must remove from the schedule. Also, if you experience unexpected delays or increases in coding time on some capabilities, you will be required to cut out planned work on other capabilities in order to meet a preset date. This requires careful management of expectations and communications with customers.
Influence, Not Control
As a Product Manager, if you are not personally in control of Development, getting your organization to commit to fixed dates is a matter of influence, rather than direct control. You can expect to use a lot of persuasion and other forms of influence to get your company onto a more predictable and manageable development schedule.
In a back issue of this newsletter, 04001 Influence: It’s Under Your Control, I discuss how to work using influence when you don’t have control over a situation or group of people.
Go Ahead, Go For Control!
Of course, if you can get the full backing of top management, and either the backing or agreement of those in charge of Development, you have the equivalent of control, and might as well push your case for all it’s worth. And the benefits of predictable development usually prove themselves, so that over time you’ve got buy-in across the company.
It may take you some time to get to such a point of control, however. You only have a problem if your timeline for getting product release dates under control is longer than your timeline for staying at the company!
One Step At a Time
Which leads us to the fact that moving to fixed dates is a cultural change, and like all such changes, takes time in addition to the effort you devote to it. You may need to go one step at a time.
For example, you can begin to build a habit of committed dates only for individual projects within a given release. Then you move to getting a release out within two months of the initial date commitment. Set the expectation that you might be up to two months late, or up to two months early. And if you have the opportunity to back-load the development cycle with minor features, you can surprise everyone by cutting out these minor features and coming out with a release earlier than expected, and everyone – QA, Development, Marketing, and Sales – discovers how nice that can be.
Then, after you have built up some faith within the company that capabilities will actually be dropped to meet a date, you may be able to pull off a date target that Development hits right on the nose.
Realize that if you’ve got a six month development cycle, which is relatively short these days, such an approach already means a minimum of 18 months before you get there.
Inside Dates and Outside Dates
One way to be more comfortable with committing to dates, and to get the agreement of Development and other departments, is to have dates that you publish to the outside world that are different than the ones you publish to customers and the market, so that you have some buffer time built in. For example, while you announce that a release is coming out on May 1, you actually only plan development and QA as if the release were due on March 1. You use the window of time in between the “hidden” and the “open” date to handle delays (no adding additional features), to do additional QA, or you begin development on the next release without telling the outside world.
In some organizations, Marketing and Sales might even fall within your definition of “outside” if they can’t be counted on not to demand new features or sell the product early.
What Does “Meeting” the Date Mean?
And then there’s the definition of “meeting” a committed date. If your previous release was one year late, and the next one is two weeks late, who cares if you didn’t meet the exact date? You came so much closer, and two weeks is so short in the grand scheme of things, that you are fully justified in defining that as meeting the date.
Also, when you have fixed dates, what often happens is that Development says that it meets the date, but the exact truth is that loose ends are still being tied up for another week. But Development sticks to their story (“we released the product as promised last Friday”).
As long as you don’t set expectations with specific customers based on meeting the exact date, no one is the wiser, and your company comes across as reliable. A year later, that one week of tying up loose ends is long forgotten.
Find the Right Timeframe
If you want to be successful moving to fixed dates, it is an absolute must that you determine the right timeframe for your releases. Your customers might be up in arms if you crank out releases every eight weeks (especially for bigger B2B applications). Or they may be absolutely unwilling to wait for 18 months for new features. You have to find the right timeframe that provides new features at a pace that is pleasing to customers without being overwhelming.
What that timeframe is will be different for every company, and depends upon many factors. Product Management can help determine and advocate for the right timeframe, using input not only from customers and Sales but from Development and technology partners.
The Effect On Your Reputation
Releasing software according to fixed release dates can have a profoundly positive effect on your reputation in the market. Customers, who have seen all sorts of ludicrous delays from some of the top names in the industry, are impressed when you keep your promises. Prospects pick up on your confidence and competence when you explain which capabilities came out when, and when the next set of capabilities will be out.
Hitting dates accurately can give you an angle with the press. In the journalism world, “Dog Bites Man” is not news, but “Man Bites Dog” is. Well, I can guarantee you that “Microsoft Releases Latest Windows Version On Schedule” would grab my attention, and how.
The Effect On Morale
Inside your company, meeting your announced dates can have a transformational effect on morale, first in Development and QA, then in Professional Services, Marketing, and Sales. People want to feel like the direction and development of their product is stable and predictable. It makes them proud. And this leads to perhaps the most important benefit of all.
The Effect On Productivity
The increase in morale, the increase in accuracy of planning and development, the feature prioritization and time management skills that result from meeting announced dates, all lead to an increase in productivity. And it is precisely such increases in productivity that allow you to put in more features faster, and outdistance the competition, so that your product and company remain strong.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]