Providing Commitment Dates To Customers

My customers mostly were very reasonable, they would ask to provide a commitment date for a deliverable right away but would also be ok if we postponed the date later, as long as we communicated the change of plans to them early enough. Their own plans depended on our commitment dates and they wanted to be sure we were not forgetting about our agreements (I am only talking about bugs and enhancement requests here). Sounds like it should be quite easy to satisfy your customer, file all these customer requests in your internal request/bug tracking system and keep the customer informed on the progress. And yet it was really difficult to keep up with this seemingly simple process of providing commitment dates and timely updates.

The first problem was getting a date from R&D. Most R&D organizations are not driven by due dates, they are driven by release plans (where promises to customers don’t always win strategic marketing targets and other priorities). So, you can get commitment dates for the requests scheduled for the next release (1,2,3-6 months from now, depending on the methodology used) but only once the release planning has happened, which means  you get the opportunity to find out  ETAs of your customer requests only once per 1,2,3-6 months. Well, customer is already not very happy, has to wait for so long just to get the commitment. This vendor release based scheduling does not go along with the customer request/commitment based scheduling. Plus, you have waited for 1,2,3-6 months for the release planning to happen just to find out that only 1 or 2 of your 10 customer requests have been scheduled for the release. Well, I am quite disappointed also, I don’t have the commitment date for 9 out of 10 requests and my customer was hoping to find out the dates for all 10.

You could say your R&D needs to use a SCRUM/agile methodology, run 2weeks to 1month sprints/iterations and then they will be able to provide commitment dates more often (every 2weeks to 1month). Agreed, but, how many iterations ahead can you plan without defeating the purpose of the “agile”? Probably not more than 2 or 3, so again the chances are I will still be only getting a commitment for 1 of my 10 requests per 1,2,3-6 months.

So this is the reality, you only know more or less what features you will deliver in your next product release (iteration, if you use agile). As 37signals say “planning is guessing” and your next release is probably your best guess. Beyond that, who knows how requests will be prioritized?

But how do you reconcile this with the customer’s desire to see commitment dates for all its requests even if some dates are meaningless and will be re-negotiated in the future? The customer basically wants our best guess date for all its requests, including those that do not get into the next release. That is a challenge, don’t you think? One may say, “then give them arbitrary date” for those ‘beyond the release’ requests. And may be that is what we should do. Not giving any date is an option too I guess. But I am thinking, can we do anything better for our customer?

So the idea is the following, may sound quite crazy, but I still want to throw it out there. Usually once a request is filed in a request/bug-tracker it is assigned to a developer right away, in most cases to the right developer who will actually be working on it once the time comes and either “blocker” urgency or the release plan says, “go”.  At the moment planning is a prerogative of a few chosen product/marketing managers who plan for the whole team and it may become quite complex, so they can’t deal with more than a bunch of most important requests. But how about empowering everyone on the team to plan? Lets say we give everyone a powerful work-hours calendar (that predicts time-off, meetings, maybe additional statistically derived unavailable time) to plan his/her own tasks. Come on, the requests are all already assigned to the developers, don’t you think they would not be able to stack them up in this smart calendar with their best guess time estimate for each to come up with a reasonable ETA for all the assigned requests? The chosen ones can help the developers with priorities (they know the business goals better) but,  in theory, all requests (and I mean all that you find in your bug-tracker or better all that have ever been asked to be scheduled, not just the subset selected for the next release) can be scheduled easily as long as you de-centralize the planning and let everyone schedule his/her own work. And the ETAs will be more accurate this way, I am pretty sure, because everyone knows their own stuff better.

Now, consolidate all these individual schedules, and pick the top N requests that you want in your release, see where your release deadline draws the line. The best thing is that any request “beyond the release” has been scheduled also and has the best guess ETA. I would really be happy to relay that to my customer, that is the best guess he was asking for all along. What is even better, every time there is a new request in the system it trickles down into developer’s personal work-hours calendar where he/she plans it right away (may be reshuffles a few other tasks to accommodate changed priorities). We have all requests re-estimated and re-planned, we have our best guess for all of them, and the commitment date can probably be shared right away with the customer. Actually the scheduling developer sees right away which commitments he breaks when adding a new task to his calendar. At this point maybe we can re-negotiate the priorities with our customer? That is the power of de-centralization!

I would call this “continuous re-estimation” or “continuous re-planning”. You don’t wait until the next release planning session, developers re-plan their tasks as soon as priorities have changed or new tasks got assigned. May be you don’t even need release planning with such a model, because you always have your best guess schedules ready and up to date.

What do you think?

Take project related email under control

Here is another video tutorial for Yoxel PCM that shows how you could start managing requests communicated via email. Let Yoxel PCM pick them up from your Inbox and track; associate with tasks and figure out an accurate completion date; communicate a commitment date back to the request originator (http://yoxel.com/task-management.html).

Planning Tasks with Yoxel PCM

Here is a new video tutorial for our new product, Yoxel PCM. It shows how to add, organize, plan tasks (http://yoxel.com/task-management.html):

The project management discipline is in crisis

I ran into this publication, The underlying theory of project management is obsolete, a while ago and thought it was quite interesting. I finally got around to writing a digest of it. Most of the material is directly quoted from the paper.

The article starts by establishing a baseline of the current PM theory as known according to the PMBOK Guide.

Theory of Project is described by these three principles:

1. Project management is about managing work; this is the conceptualization.
2. The work can be managed by decomposing the total work effort into smaller chunks of work, which are called activities and tasks in the PMBOK Guide.
3. Implicit assumption associated with decomposition, namely that tasks are related if at all by sequential dependence.

Theory of Management consists of the following three sub-theories:

• Theory of Planning
• Theory of Executing
• Theory of Control

The planning processes dominate the scene in the PMBOK Guide. The emphasis is on planning, with little offered on executing especially, making the overall management theory “management-as-planning”.

The underlying theory of execution turns out to be similar to the concept of job dispatching in manufacturing where it provides the interface between plan and work.  The basic issue in dispatching is allocating or assignment of tasks or jobs to machines or work crews, usually by a central authority.

Then the article proceeds to examining the current PM theory and argues that is not the best available:

Theory of Project

The current model is basically represented by a non-cyclical network graph in which each activity connects directly into its immediate successors.  Such a model fails to account for uncertainty in production process, which affects time as well as interdependencies between tasks.

The alterative “flow view” based on the queueing theory where the focus is directed towards uncertainty and linkages models the reality much better. The flow view especially addresses the goal “unnecessary work is not done”.

Yet another theory exists,  the value generation view. The basic thrust here is to reach the best possible value from the point of the customer.  The major difference between the suggested PMBOK view and the value generation view is that the customer is included in the conceptualization of the latter. The value generation view admits that at the outset, customer requirements are not necessarily available or well understood, and that the allocation of requirements to different parts of the (project) product is a difficult problem.

Theory of Management

Theory of planning:  As for the management-as-planning approach:

• it has been held that it is not generally possible to maintain a complete and up-to-date representation of the current circumstances and the plan to change them.
• the absolute separation of management and execution is not seen to adequately correspond to organizational reality.
• the plans push tasks to execution without taking the status of the production system into account.

The two last aspects mean that this model “leaves the task of management essentially uncoupled from everyday activity” (Johnston & Brennan 1996). Also the model implies that the process and outputs of planning are not questioned.

There is another approach to management, called management-as-organizing, which has been presented as a counterpart to management-as-planning.  It models an organization as a set of interacting sub-units capable of sensing, planning and acting.  Communication is non-hierarchical, based on interaction between sub-units. In this approach, management involves design, co-ordination and enabling of otherwise autonomous activities.

Theory of Executing:  The main issue with the current dispatching model is that the unproblematic realization of tasks pushed by the plan to the execution is assumed.  It is very difficult to maintain an up-to-date plan, and thus the tasks pushed by the plan do not correspond to reality, i.e. their prerequisites in terms of predecessor tasks (or other inputs) do not necessarily exist. This leads to the situation that a major share of tasks to be commenced, when pushed by the plan, chronically lack one or more of their inputs.

Another erroneous assumption is that the task is fully understood, started and completed according to the plan once authorized. Whereas in reality the work in organizations is coordinated through making and keeping commitments. Thus action is coordinated by the commitments people make rather than by central control acting through commands.

The two basic shortcomings of the PBMOK suggested dispatching model are:

• there should be two-way communication between the controller and the executors.
• it is necessary to consider the commitment of the executor; a job will actually be started and completed only if the executor is committed to realize it.

Theory of Control: Another theory of control,  “scientific experiment”, that addresses learning and improvement  is suggested as a better approach to finding root causes for problems , and improving performance.  It reveals a fatal shortcoming of the PMBOK suggested model that does not address finding reasons for deviations, and eliminating those root causes.

The article goes on to present empirical evidence from one application domain, construction, that the existing PM theory is not valid.  The evidence is abundant, and you should read it yourself. I just want to include here one last quote:

The deficiencies of the theory of the project and of the theory of management reinforce each other and their detrimental effects propagate through the life cycle of a project. Typically, customer requirements are poorly investigated at the outset, and the process of requirement clarification and change leads disruption in the progress of the project. The actual progress starts to drift from the plan, the updating of which is too cumbersome to be done regularly. Without an up-to-date plan, the work authorization system transforms to an approach of informal management. Increasingly, tasks are commenced without all inputs and prerequisites at hand, leading to low efficiency or task interruption and increased variability downstream. Correspondingly, controlling by means of a performance baseline that is not based on the actual status becomes ineffective or simply counterproductive. All in all, systematic project management is transformed to a facade, behind which the job actually gets done, even if with reduced efficiency and lessened value to the customer.

A few points here that resonate with me personally when thinking of software development projects and project management processes used:

• Rework indeed seems to constitute the bulk of the software development projects. No wonder the non-cyclical network graph model (think MS project / GANTT chart model) mentioned earlier does not reflect the reality. The execution of the original plans never goes as planned.
• Most of the project planning sessions dont have a good way of incorporating customer feedback during requirement development and feature prioritization and so focus on product value is not always clear.
• Planning & management indeed seems to be removed from execution. Management thinks of execution as of an ideal machine. Uncertainties of the production and requirement understanding are poorly accounted for in the plans and.
• One way communication within command-and-control model. Such an important factor as commitments from your team members are usually overlooked although those are the most important elements enabling project success.

Cheers!

MS Outlook, Email, Tasks, Google Wave?

I had an interesting meeting the other week. Demo’ed our new product to a director of project management at one pharmaceutical company and tried to learn about his challanges at the same time.

The most interesting discovery was the following:

Reading e-mails and distilling project information for inclusion in project plans is a major part of what project managers do these days.

How about that? Surprised? Maybe not. Now, think of your favorite project management solution (MS Project), even one of those new web-based ones (Clarizen, Zoho, BasecampHQ, …). Do they solve this “email management/organization” problem for project managers?

Microsoft seems to realize the issue  better than anyone else then? Because MS Outlook does try to provide a solution here by integrating Email & Tasks. Although their approach is again a bit incomplete, the personal planning part is kind of missing (well, they want you to use MS Project for that I guess). But MS Project’s “command-and-control” model, I am afraid, is not going to fly. In the time of social networking, teams seem to be looking for more de-centralized approaches.

Google also seems to have realized that the email clients we use dont cut it anymore. How many times do you find yourself looking for an email message in your Inbox that had some short but quite important comment relevant to an active project? You know it is there but it is just not  easily accessible, maybe already archived by MS Outlook and gone. First, the Gmail threading email organization and now Google Wave make alot of sense to me. I think such email channels would also make alot of sense for project managers. Imagine if each request listed in your project plan had this email channel associated with it, and you could easily see all relevant email communication in it? Wouldn’t that improve productivity significantly?

-Alexey

Bookmark: Sun “cares” about Java developers

Here is an interesting blog post, JavaFX: one year later. For Java developers who hoped to adopt JavaFX and integrate it with their Swing applications, this is still a challenge and Sun is not helping. Why?

The last paragraph mentions their VP of marketing,  quite interesting:

Wait a minute, according to Eric’s LinkedIn profile, he joined Sun in February ‘08. How long has he been working on JavaFX? That guy, actually, is also an angel investor in a startup called Zoodles, which uses Adobe AIR as the technology for its rich internet application.

Go figure …

Creating a useful product management environment

More development in the area of customizing and integrating bug-tracking and project management tools to create a useful product management environment: Product management nirvana

I have pointed earlier to the effort started at Splunk in my post Bookmark: Automating and opening up product planning . It is quite interesting to see what they are trying to do. Once again, I am just glad that the vision of our project Yoxel Agile Product Management is aligned with what real agile product management teams try to address. Here is what I mean by that:

Think bigger, Think Agile Product Management

Bridging the worlds of PLM and CRM

Bugzilla -> Yoxel synchronization module

Technical reporting with YOXEL SW: HTML, PDF, EXCEL

Project management software is social software

Release planning with YOXEL SW: Starting a new release

Release planning with YOXEL SW: Collaborative planning session

Cheers!

Rolling wave planning compromise.

David @ 37signals is saying, You do not need a product road map:

It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see. 

John @ SplicedNetworks is saying, Goodbye Roadmap:

The concept of a roadmap has been thrown out, replaced with list of initial functional features . These features are currently in development, and will be the initial AppOS 4.0 release. AppOS 4.0 won’t be the bells and whistles release initially, instead it will be functional. Features will be expanded and added based on customer feedback , as well as our own use of the product.

These are agile companies talking. I support this concept and I am pretty sure they know what they are talking about. Our backlog is our idea of a road map, it is telling us what could be coming in the future releases (most probably the higher priority items) although you can not really say when exactly and in which order. One or two iterations ahead the situation is much clearer but beyond that not really, it is all driven by the changing market requirements.

But then, even scrum masters keep bringing up the concept of the rolling wave planning, which basically means: lets still try to maintain our road map and long term release plans, even though we’re agile. Isn’t that somewhat contradictory to the iterative “agile” concept which tells you that it does not make much sense to predict that far ahead?

I think Jerry Manas expressed it very well in his comment to  Forced Into ‘Agile’:

But even in the Defense Industry, Rolling Wave scheduling is becoming the norm, where each horizon is planned at a more granular level as it approaches (although the whole project is laid out up front at a higher level). I look at Rolling Wave as a hybrid between Agile and BDUF (and it’s appropriate for most projects most of the time).

So is the rolling wave a vehicle for transition to agile or a means to keep your business/management/VC folks happy (by giving them a plan that wont survive the reality)? What is your take on this issue? Do you create product road maps in your agile environment? Do you use the rolling wave concept? How practical is that? It would be very curious to learn.

Our product Yoxel Agile Product Management  is quite straight forward in this sense. You’ve got your backlog and your iterations, which we also call incremental releases, because for us those are the same (~1month: implementation+testing). No rolling wave with long term release plans and even longer term road map plans. You can start planning next iteration while you’re implementing/testing one and so you will have a good idea for what is coming in a month or two but beyond that your best bet is the prioritized baclkog :).

Cheers!

Installable vs. Hosted

This 37signals’ post started a long thread of interesting comments Ask 37signals: Installable software? Quite insightful opinions although mostly leaning towards the hosted SaaS approach.

It would be highly unlikely that we’d sell installable software. This question is actually more about business than it is about software. 

• We’d be a different company
• Hosted = Controlled development and deployment environment
• Installable = Lots of room for things to go wrong
• Backward compatibility headaches
• Upgrade cycles

And then also this interesting follow up  Installable vs. Hosted , by Kevin Dangoor, in defense of installable software.

However, I think for a many apps, quite a few potential customers will be left behind by only offering a hosted version.

I’ve seen a number of products start off with one approach and then add the other. I can name two off the top of my head that started off installable and added a hosted option.

Our experience is quite opposite, we have started with a hosted version and later added an installable one. We distribute a free open source version of our product so if you study and de-bug our code it is fine with us, that only helps us make it better 🙂

The SaaS model was a good start, it helped us to mature our product and test the market. It is a significant part of our offering. One of the main reasons though vendor companies choose SaaS model is because it is easier for them. You do not have to worry about all those bullets expressed by 37signals. Is it always a good model for your customer? Not always, if you start paying more attention to your data security and privacy.

Our SaaS/OnDemand version offers a number of free services and we do not lock-in your data (you can always take it and move to your own server). And still, we see that more users prefer to download our open source version and install it on their premises (even though it takes some of their precious time). I bet the data security (in our case we are talking about release/project/feature plans) and in some cases compliance with Sarbanes-Oxley Act plays significant role in their decision making process. We are not Google or Salesforce so we did not expect that everyone would trust us with their critical business and customer related data so we went for an installable version too. And it has been quite rewarding: more users, more useful feedback, our code improved significantly, even the article in O3 magazine.

Our software is riding on UAMP (Unix,Apache,MySQL,PHP) stack which makes it easier to produce the installable version of our product. The release and testing process actually makes our SaaS solution (http://yoxel.com) much more robust. It was quite a challenge and alot of work to create a proper development infrastructure and to start producing the installable version but now after over a year of releasing it I should say it is not that hard anymore.

There are many advantages for a vendor to use SaaS model but here are a few that I personally like in the installable open source software model too:

• More potential customers who otherwise would be concerned with SaaS
• We are not responsible for the security and privacy of customer servers/data
• You can test at a few selected beta-sites before rolling out new version to everyone
• Our users help us make our software much better by seeing our code

We really like our SaaS model too. Would the trust/security/privacy issue be easily solvable this would be just enough, I think. But at the moment the combination of hosted and installable makes alot of sense to us. Appliance is a good model too, unfortunately we have not reached that stage yet. A good example is SugarCRM which offers all three models!

Enjoy!

http://yoxel.com

Bookmark: Automating and opening up product planning

Here is an interesting post by Christina Noren, Automating and opening up product planning. Yet another example of a team trying to hack and integrate a few existing tools to build a useful product management flow. The problem I have been describing in my earlier post, Think bigger, Think Agile Product Management. Seems like many teams face the same inconvenience and some new, more integrated tools could help.

So the experiment: We’re hacking Jira, our bug tracking system, in order to automate the entire product planning and marketing process and facilitate real-time communication back to customers, internal stakeholders and even the community at large via our public roadmap. 

…

This means that we setting it up to automatically bring enhancement requests from our SugarCRM system into a PM work queue within Jira; asking PMs to enter call reports and market datapoints; linking all of these to problem statements;

What I especially like about this post is that it confirms our efforts with our project Yoxel Systems. Yoxel is exactly that integrated system: request tracking, release planning/tracking, key CRM capabilities, and even customer portals! And if you really like your Jira, Bugzilla, Mantis, GNATS, Yoxel can connect to them too.

Customers with enhancement requests tracked through the support portal will be able to see how they’ve been triaged, how the problem has been interpreted, and what requirements are at what stage of delivery to meet the request.The public roadmap will be maintained in real time, with the potential for drilldown into more of what’s behind each listed feature. 

Once again, Bridging the worlds of PLM and CRM  seems to be creating value and helping you build better products.

Check out our demo accounts as http://yoxel.com