Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Team and Phasing Structure
The first action that I would take is get a small team together, including a business side representative and someone who understands the existing application. Then I would spend no longer than a week gathering basic requirements and designing a basic solution. I would do this before developing a project plan.
The major part of this week of preliminary design should be spent in four tasks:
- Understanding the requirements
- Designing the task/message flow
- Selecting technology
- Analyzing the task/message flow, as described earlier
At the end of this week, there should be enough information to develop a project plan and do an initial estimate of the time and resource requirements.
In this example, I would expect that, during this week, the team would identify two issues that could derail the project. The first is the use of untried technology. The organization must build the relevant skills and might need to develop additional infrastructure program code, scripts, and operational procedures. There should be a proof-of-concept study to evaluate the software and size of the learning effort.
The second possible derailing issue comes from an analysis of the required data. There will be a serious issue in either of the following two cases:
Information is required by the existing system that you do not want the Web user to input. For instance, the existing system might demand a customer reference number, and you don't expect a Web customer to know this piece of information.
The department sponsoring the new system wants to store additional information that isn't stored in the existing system.
In both cases, there will be considerable extra work, maybe so much additional work that the business sponsors of the project lose interest.
The implication of this discussion is that a proof-of-concept study and an analysis of the data requirements are tasks that should be done sooner rather than later because either could cause a cancellation of the entire project.
Assuming that the decision is to proceed, the main project splits into two subprojects:
Design and implementation of the Web server application (the front-end subproject)
Design and implementation of the back-end integration (the back-end subproject)
When the task/message flow is known, the front-end and the back-end subprojects can go forward relatively independently of each other. It is even feasible to consider running each subproject with a different style of design methodology. The front-end project might use extreme programming, while the back-end project might use a traditional approach. However, there must be an effort from each team to develop an agreed-upon interface. The back-end integration team should then develop a test version of the interface for the front-end team to use. The front-end team should develop a driver program for the back-end team to use. Forcing each team to use the other's code will quickly highlight misconceptions in the interface specification. Shortly before the end of each release cycle, there should an integration of the front-end and back-end applications.
But there will inevitably come a time when the interface needs to change. I suggest, during the project plan, that you assign a task for redesigning the interface at the start of each iteration.