Aah, this is one of the most difficult posts to write, since there is no magic bullet answer. Let me take a situation where you have some team members or functional folks who are not really up to working with schedules, or are disciplined about schedules as the development or testing members of the team. What happens typically ? You have a schedule that has been worked out pretty diligently, that takes into account the work of different team members and functional folks, and gets them all integrated with each other to have a schedule that promises, if you follow the schedule, that you will have your software application ready.
So if everything is going well, if the project management structure of the team is tracking the schedule and the entry and exit of each of the team members as per the schedule, then everything can work out. Further, a lot can be done to help in the process, by setting up systems that provide advance schedule information to the team members, before their tasks are due to start, as well as close to when their tasks are about to end. This can be followed by status meetings and other to ensure that team members have all the information that they need to get their tasks done, and any problems that they are having can be followed up.
However, if everything went so smooth, schedules would always work and there would never be any kind of problems regarding risks, and so on. One of the biggest elements of risks in the entire schedule, just from the scope of delivery from the different functional teams is regarding adherence to the schedule. When you consider the functional requirements of the schedule, you will have requirements and feature details from the product management, followed by elements of design (architectural, workflow and others) from the development and user interface designers, and then the actual development and testing. One of the biggest problems that I have seen is with regard to the more creative elements of this process, namely the user interface designer or the workflow designer. We had an interesting interface designer who would just tell us that to give him a final date by which the entire design would be needed, and not bother about interim dates since that was not the way that he worked. There is some justification, since the user interface designers tend to be creative folks who are not really as bound to a schedule as the rest of the development and testing teams. However, this can screw up the entire schedule, since the assumption is that there are dates by which the designer needs to submit a first draft and there are iterations through which this draft is discussed, and then finally agreement is reached on the final draft to be used for the product development.
So, what do you do ? Well, here are some techniques that we used:
- Ensure that there is ongoing communication with the designer. Typically, it was during a regular phone call that we would find out about some issue that the designer was running into, but which the designer had not told us about via email.
- Remind the designer on a regular basis when the schedule for either the start of the tasks or the end of the tasks was coming up to ensure that this was on the top of the mind
- Add some buffer to the schedule of the user interface designer, and start harassing from the first schedule so that you know that you can expect to get the work by the buffer date
So if everything is going well, if the project management structure of the team is tracking the schedule and the entry and exit of each of the team members as per the schedule, then everything can work out. Further, a lot can be done to help in the process, by setting up systems that provide advance schedule information to the team members, before their tasks are due to start, as well as close to when their tasks are about to end. This can be followed by status meetings and other to ensure that team members have all the information that they need to get their tasks done, and any problems that they are having can be followed up.
However, if everything went so smooth, schedules would always work and there would never be any kind of problems regarding risks, and so on. One of the biggest elements of risks in the entire schedule, just from the scope of delivery from the different functional teams is regarding adherence to the schedule. When you consider the functional requirements of the schedule, you will have requirements and feature details from the product management, followed by elements of design (architectural, workflow and others) from the development and user interface designers, and then the actual development and testing. One of the biggest problems that I have seen is with regard to the more creative elements of this process, namely the user interface designer or the workflow designer. We had an interesting interface designer who would just tell us that to give him a final date by which the entire design would be needed, and not bother about interim dates since that was not the way that he worked. There is some justification, since the user interface designers tend to be creative folks who are not really as bound to a schedule as the rest of the development and testing teams. However, this can screw up the entire schedule, since the assumption is that there are dates by which the designer needs to submit a first draft and there are iterations through which this draft is discussed, and then finally agreement is reached on the final draft to be used for the product development.
So, what do you do ? Well, here are some techniques that we used:
- Ensure that there is ongoing communication with the designer. Typically, it was during a regular phone call that we would find out about some issue that the designer was running into, but which the designer had not told us about via email.
- Remind the designer on a regular basis when the schedule for either the start of the tasks or the end of the tasks was coming up to ensure that this was on the top of the mind
- Add some buffer to the schedule of the user interface designer, and start harassing from the first schedule so that you know that you can expect to get the work by the buffer date
No comments:
Post a Comment