One differentiator between standard and custom software development projects is that on custom projects, customers will have commitments that they have to meet in order to achieve the schedule.
On standard software developments, customers are contacted prior to beginning the development in order to get feedback on the features in the software which are important to those customers. But once the development goals are defined in the specification, very little customer involvement will take place, except for the possibility of having the customer do some pre-release “beta” testing of the program.
On custom software development projects, the customer will have more significant involvement in completion of the project. First and foremost, the customer needs to agree on the definition of the project’s features and scope as described in the SRS. But in addition to that, the customer may need to provide the actual servers and/or workstations that will be used in the implementation. Occasionally other specialized equipment must be supplied by the customer. Often, for testing purposes, the customer needs to provide test data
So one key aspect of managing custom software design projects is managing the customer in order to help them recognize and meet these various commitments. The project plan is an important tool to use for this purpose.
The customer should also be included in the project plan as one of the resources. Anywhere within the project plan that you need something from the customer (approval of a specification, delivery of some test data, etc.) make sure that the task is listed and assigned to the customer. In all cases, the customer should be made aware of the commitments that have been assigned to them when the project plan is first approved and whenever it is updated.
For all such customer commitments, you should also add a preliminary task, assigned to the project manager, to remind the customer of upcoming commitments that have been assigned to them. When the project manager reminds the customer, the reminder should be as a gentle reminder, in writing (most likely an email) and the reminder should lay out for the customer the schedule implications if the commitment is not met or if it is delayed.
And, of course, these tasks / commitments should be reviewed whenever there is a project review meeting with the customer. The project manger’s own managers should be aware of all such customer commitments, especially when the customer does not meet any such requirement.
So why do all of this? Is it simply to cover your ass (CYA)?
Admittedly that is a part of it. But much more importantly you must understand the customer’s perspective of the project.
The customer is very interested in meeting the schedule. In fact, as I’ve mentioned already, I believe that in most cases the schedule is the most important single aspect of the project for the customer - especially if the solution is based on a fixed-cost quote. But the customer is depending on the vendor to provide the solution within that schedule. It is easy for them to overlook those things that they need to provide.
I’ve never seen a customer who complained about being reminded of their own commitments. But this is one of the reasons that the vendor should have a good relationship with the customer.
On standard software developments, customers are contacted prior to beginning the development in order to get feedback on the features in the software which are important to those customers. But once the development goals are defined in the specification, very little customer involvement will take place, except for the possibility of having the customer do some pre-release “beta” testing of the program.
On custom software development projects, the customer will have more significant involvement in completion of the project. First and foremost, the customer needs to agree on the definition of the project’s features and scope as described in the SRS. But in addition to that, the customer may need to provide the actual servers and/or workstations that will be used in the implementation. Occasionally other specialized equipment must be supplied by the customer. Often, for testing purposes, the customer needs to provide test data
So one key aspect of managing custom software design projects is managing the customer in order to help them recognize and meet these various commitments. The project plan is an important tool to use for this purpose.
The customer should also be included in the project plan as one of the resources. Anywhere within the project plan that you need something from the customer (approval of a specification, delivery of some test data, etc.) make sure that the task is listed and assigned to the customer. In all cases, the customer should be made aware of the commitments that have been assigned to them when the project plan is first approved and whenever it is updated.
For all such customer commitments, you should also add a preliminary task, assigned to the project manager, to remind the customer of upcoming commitments that have been assigned to them. When the project manager reminds the customer, the reminder should be as a gentle reminder, in writing (most likely an email) and the reminder should lay out for the customer the schedule implications if the commitment is not met or if it is delayed.
And, of course, these tasks / commitments should be reviewed whenever there is a project review meeting with the customer. The project manger’s own managers should be aware of all such customer commitments, especially when the customer does not meet any such requirement.
So why do all of this? Is it simply to cover your ass (CYA)?
Admittedly that is a part of it. But much more importantly you must understand the customer’s perspective of the project.
The customer is very interested in meeting the schedule. In fact, as I’ve mentioned already, I believe that in most cases the schedule is the most important single aspect of the project for the customer - especially if the solution is based on a fixed-cost quote. But the customer is depending on the vendor to provide the solution within that schedule. It is easy for them to overlook those things that they need to provide.
I’ve never seen a customer who complained about being reminded of their own commitments. But this is one of the reasons that the vendor should have a good relationship with the customer.
No comments:
Post a Comment