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

Why do organizations fall back to the old, comfortable waterfall?

Here is another article that I really liked: The (Not-so) Agile Waterfall, by Ken Knapton.

I have recently been made aware of yet another organization that says they are “doing agile” when in fact they are not. They are in fact following almost a text-book example of the waterfall method, but using agile terms such as “iteration” and calling it agile. They define every iteration up front, and lock themselves into dates when each iteration will be completed, even for projects that will last six months or longer. The development team is strictly held to meeting these dates, and product is not delivered until the end of the project. 

And why does this happen? Ken suggest one reason:

As to the question of why organizations fall back to the old, comfortable waterfall, I believe it comes down to a very simple answer: metrics. Upper management likes to have nice metrics to track the progress of their organization, and the easiest metric to track is on-time delivery.

I guess for the same reason some commercial ALM tools lure you into this trap too. They sell their tools to those managers after all. Their marketing works way too well promoting “agile”:

• Check out RallyDev’s demo: slide#2 talks about roadmap, release, iteration planning. What I get from this is that they suggest to plan a release (3-6 times a year) and lock iterations within that plan. I am not exactly sure what good a 4months plan with locked iterations will do if after your first iteration (2weeks to 1month) your customer feedback shows that you need to re-prioritize and change half of the plan. Or, aren’t you delivering functional software to your customers after each iteration for feedback?
• How about VersionOne’s datasheet: One of the key features Drag-n-Drop release and iteration planning. As for agile, I understand iteration planning or just release planning (if it is a short incremental one, equivivalent to an iteration), but together? This probably means again, create a waterfall plan and lock your iterations within it. Is that agile?

In general if you’re trying to be agile you will have hard times planning something far away in the future. Giving dates for your future releases and roadmap milestones is quite a challenge:

Does “agile” complicate your roadmap management process?

Agile roadmap 

Yoxel v1.18: License Management System (LMS)

 Yoxel v1.18 is available for download with a significant extension to YOXEL SLS (for sales) suite: License Management System. You may ask, “Why YOXEL SLS?” – when the focus of the project is agile product management. The reason is that our active users encourage us more and more to link into CRM world and as I wrote before this seems to make alot of sense: Bridging the worlds of PLM and CRM

So what is this License Management System?

Think of it as of yet another flavor of Yoxel request tracker. The requests ask to cut a license (produce a license file) for a customer, deliver it to the customer, and confirm that it is installed successfully. That is what your customers and eventually your sales people request internally from your R&D, Support, or IT team (whichever is in charge of your license cutting process), and if you have many customers and many such requests you’d better keep it all organized. So there is a certain workflow for the requests (customization is of cause possible), and here are the main states of the default workflow:

• State ‘open’ – a sales guy files a request. At this point the sales can help by specifying required details: license server platform, hostid, list of individual feature keys and their parameters (#keys, expiration dates, …).
• State ‘assigned’ – the request gets automatically assigned to a technical owner of the account (your support or sales engineer). This person will cut the license himself or work with other department to get the right license file.
• State ‘generating license’ – the technical owner is working on generating the license. He will generate the license file externally and then attach it to the request. We have also provisioned a feature-set construction panel and hooks for running external license-generators (require some customization work) so that license cutting itself could be done from Yoxel too. So the owner simply constructs the feature set from available keys and then presses button ’save’ – the license is generated and the file is attached to the request.
• State ‘license ready’ – the license is ready so it can now be sent to the customer
• State ‘verified’ – the customer has confirmed that the license has been installed and is working.
• State ‘closed’ -the request has been complete!

Purchase Order Tracking?

In many cases each license request is a result of a purchase order (PO) that has come in from a customer. This means that the a $$ amount could be associated with each request too. We have provisioned a field (booking) for that but in this 1st version of the LMS we would like to stick to the technical side of the license tracking and generation mostly. Your feedback on the PO part would be very appreciated.

Feature set construction

Besides pure tracking capability of the LMS another key part of the system is license key management. License files are usually constructed as a set of individual keys, each enabling a certain product or feature. People that use Macrovision’s FlexLM are very familiar with the concept of Time Based Licenses (TBL) and license files that are sets of those feature keys. So the LMS allows you to define all your available keys, their descriptions, and their fee information. Then at a license submission stage or license generation stage one can easily construct/modify a set of required keys and use that for license file generation.

Once-off, TBL, and billing/maintenance fees

There are many different software licensing schemes: charge once per installation, bill periodically as long as the product is in use, get a payment ahead of time for a license that will expire (TBL), … We have tried to accommodate a few popular strategies. You can associate all this fee related information with any key that you define. Then when a feature set is constructed, that is when you specify a desired list of keys, #keys, expiration dates the LMS computes for you final once-off amount, pre-payment TBL amount, billing/maintenance amount. This is meant to be used as a worksheet mostly, to have a good idea of what kind of fees your license file is entailing. The actual booking amount entered for a request is up to the sales person (ideally it is the once-off fee + the TBL sub-total). The worksheet also informs you of planned billing schedule.

Check it out

So the 1st version of LMS is available for you to try at our demo accounts at http://yoxel.com and for download. I am sure it is not perfect yet and requires quite a few useful features to be added, we have some interesting ideas and will be enhancing the system in the next releases.

v1.18

To see what else is new in v1.18 please visit our news section at http://yoxel.com and explore our demo accounts.

Enjoy!

Yoxel v1.17 with a SALES module is available for download.

Release v1.17 (http://yoxel.com) has a bunch of new capabilities and I am quite excited to list a few of them here:

1. YOXEL SLS (an experimental suite for sales teams), that has been only available in our on-demand version, is now included in the open source version. You get two subsystems: sales forecast tracking and product evaluations tracking. Many other CRM products have forecast/opportunity tracking solutions but you will not see many good product evaluations tracking solutions. We would like to think that ours are quite unique and powerful, plus they become integral part of the whole product management solution:
   

   Bridging the worlds of PLM and CRM

2. Profile editing capabilities added for customer/contact logins. Besides entering contacts information only on your side (correct name/email/password/opt-out options/…), the traditional CRM way, you can now rely to some degree on the contact itself. Certain fields have been opened for your contacts, that have login access privileges, for editing. This kind of makes it CRM 2.0 – more interactive relationship with your customers and better feedback management .
3. CVS and basic Subversion integration is enabled though email comments support. Besides capturing email responses related to requests and attaching them to the request history/log, Yoxel in a similar way now can attach your commit messages coming from CVS or Subversion.
4. Responding to a request from one of our users, support for Retrospectiva external bug-tracker has been added too. Now it is possible to configure Yoxel to import requests from one of these bug-trackers: Bugzilla, GNATS, Mantis, Retrospectiva. For a smooth transition to “agile”!
5. … other more specific capabilities and bug fixes …

Ejoy!

PS: And please send us your feedback.

Areas to improve for your software projects

A very insightful analysis indeed, by Carl Rogers in his post A little insight into our customers’ process capability …

With tons of useful graphs. A few things that I notice from the graphs:

1. The most challenging problems that software projects face are: Delayed Delivery, Cost overruns, Poor Requirements, Unclear/Imprecise Business Objectives, Poor Communication, Lack of Testing
2. Importance of software development process in building applications: hight for the most teams
3. Use of software development process: In-house grown is the most popular one especially for smaller teams, compared to others like MSF, SCRUM, …

Clearly known agile methodologies emphasizing incremental delivery and frequent customer feedback management focus on solving #1 challenges and must be the only right way to go.

For the most part this survey results seem to be in agreement with the other survey that I mentioned earlier, done specifically for agile methodologies: Agile Project Management Tooling

The only major difference I see is that in Carl’s results the in-house/hybrid methodology and MSF are the most popular ones whereas in the other survey it is SCRUM and XP.

PS: Here is another article that seems to be quite relevant to the topic of the problematic areas for software projects: The Absent Product Owner anti-Pattern