Project Insights
Some tips and lessons that I have gained from my project experience delivering cloud solutions in the Salesforce platform.
1 - Keep the end goal in mind
Information, and more importantly insightful business information that can drive effective decision making is key for any business. I have often seen projects nearing their end, where the business asks - so what can I make of this data. The end business goals should be understood by the full and wider project team, to ensure the solution is being driven towards the end goal. To narrow down on one particular detail - Reporting must never be an after thought but should be defined early on in the project, and the implementation guided to ensure the business will have the data they need.
2 - More than just a use case
I have seen many project disputes raised over the finer details of Use Cases when an agile approach has been adopted on a project. It is important that both the business and developers understand that the Use Case represents a high level view of the functionality, and that the detail does require many sessions and revision with the business to really understand what they are after. Nothing beats an early prototype or show-and-tell to demonstrate clear understanding of what the Customer is looking for, and this can save invaluable time later on in the development lifecycle. Disputes can occur with customers when details were not defined earlier, but at the same time, it is very difficult for a customer to articulate their needs if they are not conversant with the scope under which the new system operates. Patience and close interaction is the key here.
3 - Deliver - Refine - Redeliver
Building on the point above, an iterative development lifecycle is important to making sure we get it right for the customer. Misunderstandings can be clarified and detailed definitions formed that really guide the system build as we go though the project lifecycle.
4 - Finding the balance between onshore and offshore
Most projects will incorporate a balance of on-shore and offshore resources and it is important to have a solid delivery approach in place to ensure a single combined team can work in harmony. The offshore team should be given a sense of ownership and made to feel part of a combined team. Video conference sessions, early design involvement, early introduction of the client to the offshore team, 1 week onshore stints - these are all ways that the offshore team can be made to feel engaged on the project. The sense of engagement and ownership and conveyance of importance is key to make best use of the talent pool most organisations have offshore. Simply giving offshore a requirements spec of giving them odd monotonous tasks does not grow team harmony or engagement. Tasks like these should be balanced between on-shore and offshore teams.
5 - Blueprinting Phase
A project must start with a blue-printing phase - a 1-2 week workshop to determine what the business is looking to achieve, and what the high level requirements of the system need to be. Walkthroughs can help with this, allowing senior architects enough time to understand and plan what will need to be delivered to meet these business goals, and define the scope of the project. This phase should be conducted independant of the delivery phase. A separate contract of engagement should be formed once blueprinting is complete. This will ensure that the team has a better sense of what is required and can adequately arrange for the right resources and time to provide the customer with the right cost.
These are some among many lessons learnt over time. Hope you read these items and considering implementing them in future projects.
1 - Keep the end goal in mind
Information, and more importantly insightful business information that can drive effective decision making is key for any business. I have often seen projects nearing their end, where the business asks - so what can I make of this data. The end business goals should be understood by the full and wider project team, to ensure the solution is being driven towards the end goal. To narrow down on one particular detail - Reporting must never be an after thought but should be defined early on in the project, and the implementation guided to ensure the business will have the data they need.
2 - More than just a use case
I have seen many project disputes raised over the finer details of Use Cases when an agile approach has been adopted on a project. It is important that both the business and developers understand that the Use Case represents a high level view of the functionality, and that the detail does require many sessions and revision with the business to really understand what they are after. Nothing beats an early prototype or show-and-tell to demonstrate clear understanding of what the Customer is looking for, and this can save invaluable time later on in the development lifecycle. Disputes can occur with customers when details were not defined earlier, but at the same time, it is very difficult for a customer to articulate their needs if they are not conversant with the scope under which the new system operates. Patience and close interaction is the key here.
3 - Deliver - Refine - Redeliver
Building on the point above, an iterative development lifecycle is important to making sure we get it right for the customer. Misunderstandings can be clarified and detailed definitions formed that really guide the system build as we go though the project lifecycle.
4 - Finding the balance between onshore and offshore
Most projects will incorporate a balance of on-shore and offshore resources and it is important to have a solid delivery approach in place to ensure a single combined team can work in harmony. The offshore team should be given a sense of ownership and made to feel part of a combined team. Video conference sessions, early design involvement, early introduction of the client to the offshore team, 1 week onshore stints - these are all ways that the offshore team can be made to feel engaged on the project. The sense of engagement and ownership and conveyance of importance is key to make best use of the talent pool most organisations have offshore. Simply giving offshore a requirements spec of giving them odd monotonous tasks does not grow team harmony or engagement. Tasks like these should be balanced between on-shore and offshore teams.
5 - Blueprinting Phase
A project must start with a blue-printing phase - a 1-2 week workshop to determine what the business is looking to achieve, and what the high level requirements of the system need to be. Walkthroughs can help with this, allowing senior architects enough time to understand and plan what will need to be delivered to meet these business goals, and define the scope of the project. This phase should be conducted independant of the delivery phase. A separate contract of engagement should be formed once blueprinting is complete. This will ensure that the team has a better sense of what is required and can adequately arrange for the right resources and time to provide the customer with the right cost.
These are some among many lessons learnt over time. Hope you read these items and considering implementing them in future projects.
Comments
Post a Comment