I have a question regarding conversion work and how it is typically reported on FDD projects. We are currently developing a second release of an application that is already live. As such we have a small but none-the-less critical conversion activity that involves the creation of some conversion sql scripts and a mechanism to import conversion data from an external system by a batch process. Therefore there are several conversion activities that need to be done during the development phase to prepare these scripts/mechanisms ready for use on 'go live' day.
At the start of the project we derived PD, UI and SI features and didn't include conversion development activities in these lists. In our project estimates and plans the conversion work was however included. My concern is that we have been reporting progress to management based on the three feature lists and, although we have set the expectations that the conversion activities are not included in the lists, haven't been reporting on conversion progress. I understand that most development activities (such as setting up continuous build machines, etc) are not client valued and hence shouldn't be used in reporting, but what about conversion? (The customer does care about that!) If I report 100% completion of the PD, UI and SI it may be expected that development effort is finished which isn't quite true. Would it be useful to create a fourth feature list to report the progress of conversion, and hence explicitly highlight that development isn't quite finished?
Doug, I think it's hard to
Doug,
I think it's hard to classify the conversion activity as client valued.
Firstly, I think this is something that would probably be handled with conventional project management techniques. Conversion is not a 'feature' of a system, rather an activity/work product that needs to happen to facilitate use of the system. So while the customer indirectly cares about it being implemented, it is more the responsibility of the development team to ensure this happens so the customer can use the system.
Secondly (and i think more importantly), conversion is not limited to being implemented in java or any oo language. Conversion is usually done with a bunch of sql scripts or if some level of reporting is required, then something like perl would be ideal.
Of course, I haven't had much exposure to project management with FDD but I wouldn't create a fourth feature list just for conversion.
I think you've answered your own question
Hi Doug,
basically if there is work you want the same sort of visibility into, and communicability from, as the other project aspects (such as PD) then you create a project aspect for that work. Have a read of this part of another thread and see if that helps.
We can pickup the client-valued part of this question later (if need be).
Jeff
Hi Douglas, I currently face
Hi Douglas, I currently face the same situation as you do, althought we don't call it convertion but migration.
Has you have identified this may be not a client valued functionality althought critical for the completion of the project.
I've classified it within in my current project "System Integration", a major business subject in my project althought more technical.
Douglas: "If I report 100% completion of the PD, UI and SI it may be expected that development effort is finished which isn't quite true."
That is it, without finishing the feature "migrate X to Y", SI is never 100 % complete, so reporting is accurate.
Example:
Migrating Content
* migrate old security roles to roles.
* migrate old articles into to articles.
* migrate old security profiles to roles.
* migrate old folders to content repository
* etc.
Another approach would be to put this within the PD. For instance in some business activity such as "Creating Folders" one could put the feature "migrate old folders to content repository".
Regards,
Nuno Lopes.