Project Management CRM Best Practices - Project Workplan
This is the continuation of a series of posts regarding the Project Management CRM best practices.
Today I will talk about how to create a planning horizon without compromising the CRM solution in the future and is performance.
After the project definition has been prepared (see my previous post about planning), the workplan can be created. The workplan provides the step-by-step instructions for constructing project deliverables and managing the project, please try not to do copy & paste of previous projects, we always need to reflect what we going to deliver in each stage and the customer need to be aware of our task for that week or month (last case scenario) this also depends if we have week deliverables or not.
Create a workplan as detailed as possible with resources assign, estimations and dependencies but count always with some security pool as far out as your developers feel comfortable. This will be your planning horizon but bear in mind certain details like creating 200 fields in just one entity, this will have impact on performance later on with the extension of the product for other business areas, so this will be the a design issue, so for that reason is necessary to review the project design after each deliverable for the next models/functionalities to be implemented. If that features is still not sign off from the customer and we only have a draft of it.
After the planning horizon, we need to go to a higher level so we can decrease the level of uncertainty by planning this our horizon we will move forward as he project progress, high-level activities that were initially vague need to go down to the level of a feature, plugin, custom workflow actitivy or even javascript, so the level of detail will get closer in terms of timeframe. On most of the projects and depending the time we got for development, project management or business analysis, we should always go for a level of feature, and on this feature we will include all the plugins, custom workflows and javascripts related to that feature, so this will help us on dividing the releases by solutions per feature (if we are not merging solutions or package deployer), Any way this solution creation is a matter of architecture than project management.
Today I will talk about how to create a planning horizon without compromising the CRM solution in the future and is performance.
After the project definition has been prepared (see my previous post about planning), the workplan can be created. The workplan provides the step-by-step instructions for constructing project deliverables and managing the project, please try not to do copy & paste of previous projects, we always need to reflect what we going to deliver in each stage and the customer need to be aware of our task for that week or month (last case scenario) this also depends if we have week deliverables or not.
Create a workplan as detailed as possible with resources assign, estimations and dependencies but count always with some security pool as far out as your developers feel comfortable. This will be your planning horizon but bear in mind certain details like creating 200 fields in just one entity, this will have impact on performance later on with the extension of the product for other business areas, so this will be the a design issue, so for that reason is necessary to review the project design after each deliverable for the next models/functionalities to be implemented. If that features is still not sign off from the customer and we only have a draft of it.
After the planning horizon, we need to go to a higher level so we can decrease the level of uncertainty by planning this our horizon we will move forward as he project progress, high-level activities that were initially vague need to go down to the level of a feature, plugin, custom workflow actitivy or even javascript, so the level of detail will get closer in terms of timeframe. On most of the projects and depending the time we got for development, project management or business analysis, we should always go for a level of feature, and on this feature we will include all the plugins, custom workflows and javascripts related to that feature, so this will help us on dividing the releases by solutions per feature (if we are not merging solutions or package deployer), Any way this solution creation is a matter of architecture than project management.
Comments
Post a Comment