Plan, plan, plan...
The woes of much of the software development business is rooted in failure to plan. I don't mean a rigid plan that everyone follows blindly off a cliff, but rather a plan which mirrors reality and is updated regularly.
Let me start by relating a story two associates told me about a project which went south. I'm sure everyone involved in software development or management has their own version of this story.
My associates were contracted to develop a relatively complex web application. The client had a fairly good idea of how the web application should appear and how it should behave. But underneath the web application was quite a bit more than just some html and javascript -- the application relied on a mix of .NET, php, C++ DLL's, Flash and a lot of tricks to bring it all together. On the surface, the job was fairly straight-forward (or at least it appeared to be); underneath, there were a lot of tasks which were not as obvious.
My two associates and the client quickly signed a contract and embarked on the programming with the most optimistic of expectations. As soon as the programming started, it became clear to my associates how many details needed to be addressed. The client was not updated on these developments, so he expected the application would be delivered as originally contracted. Then the first milestone date arrived.
At this point, my associates were to deliver an application with a certain set of working web pages. However, they delivered no pages, to the consternation of the client, whose confidence in the team plummeted. Why did they deliver an application with no pages? Because they spent the initial time creating portions of the invisible sub-structure, not on the visible presentation of the data.
The project continued to fail to meet expected milestones. Eventually, the client lost confidence entirely, and pulled the plug on the project.
The moral of the story? Quite simply, you've got to set appropriate expectations. What does this have to do with planning? Planning gives you the expected critical path through the project so you can match appropriate deliverables with milestone dates.
This sounds like the rigid up-front plan I advised against up above, but it's not. The plan you need to make is your best up-front attempt to visualize how the whole project will proceed, which is then updated regularly to keep it in synch with reality.
I learned this over the past fifteen years or so of contract software development. My proposal process always included an analysis which reduced the project to a series of tasks which I expected would take between one-half day and one day. Of course, I didn't share the details of this analysis with prospects; I simply provided a list of milestones and deliverables. However, this task list gave me great assurance that the milestones proposed in contracts were based on sound quantitative reasoning.
Without exception, projects did not proceed as initially envisioned. Usually there were tasks I underestimated or overlooked, or in some cases the client changed his mind about what the software would do or look like. Regularly (often every other day) I updated my list of tasks to reflect what had been done and what needed to be done to complete the project.
When these changes began to materially affect the schedule, I notified the client, who -- almost without exception -- accepted the schedule changes because I could articulate the reasons why the schedule had to change. Invisible sub-structure tasks became visible to the client and were considered part of the deliverables. Expectations moved with reality.
Over time, I implemented a web-based tool which allowed me to quickly dissect a project into tasks and to update the list of tasks with a minimum of effort. In certain situations, I provided the client with access to this task list so he could see exactly what was and was not done at any given point. I'm still working on this tool to provide a summary capability so clients can see, with a single glance, where projects stand.
Learning to plan, and to update plans regularly, requires a lot of discipline and support. I've found that most programmers don't stick with it unless they are regularly coached and supported until the planning process becomes a habit. Convenient tools make the process of forming this habit a lot faster and easier.
When I explained my planning technique to my associates, they laughed and said that their web application project would probably have gone an entirely different way if they had taken my approach. When I took them through the paces of dissecting one of their current projects into a task list, I could see the spark of insight in their eyes which told me they understood this type of planning is essential for the success of any project.
Let me start by relating a story two associates told me about a project which went south. I'm sure everyone involved in software development or management has their own version of this story.
My associates were contracted to develop a relatively complex web application. The client had a fairly good idea of how the web application should appear and how it should behave. But underneath the web application was quite a bit more than just some html and javascript -- the application relied on a mix of .NET, php, C++ DLL's, Flash and a lot of tricks to bring it all together. On the surface, the job was fairly straight-forward (or at least it appeared to be); underneath, there were a lot of tasks which were not as obvious.
My two associates and the client quickly signed a contract and embarked on the programming with the most optimistic of expectations. As soon as the programming started, it became clear to my associates how many details needed to be addressed. The client was not updated on these developments, so he expected the application would be delivered as originally contracted. Then the first milestone date arrived.
At this point, my associates were to deliver an application with a certain set of working web pages. However, they delivered no pages, to the consternation of the client, whose confidence in the team plummeted. Why did they deliver an application with no pages? Because they spent the initial time creating portions of the invisible sub-structure, not on the visible presentation of the data.
The project continued to fail to meet expected milestones. Eventually, the client lost confidence entirely, and pulled the plug on the project.
The moral of the story? Quite simply, you've got to set appropriate expectations. What does this have to do with planning? Planning gives you the expected critical path through the project so you can match appropriate deliverables with milestone dates.
This sounds like the rigid up-front plan I advised against up above, but it's not. The plan you need to make is your best up-front attempt to visualize how the whole project will proceed, which is then updated regularly to keep it in synch with reality.
I learned this over the past fifteen years or so of contract software development. My proposal process always included an analysis which reduced the project to a series of tasks which I expected would take between one-half day and one day. Of course, I didn't share the details of this analysis with prospects; I simply provided a list of milestones and deliverables. However, this task list gave me great assurance that the milestones proposed in contracts were based on sound quantitative reasoning.
Without exception, projects did not proceed as initially envisioned. Usually there were tasks I underestimated or overlooked, or in some cases the client changed his mind about what the software would do or look like. Regularly (often every other day) I updated my list of tasks to reflect what had been done and what needed to be done to complete the project.
When these changes began to materially affect the schedule, I notified the client, who -- almost without exception -- accepted the schedule changes because I could articulate the reasons why the schedule had to change. Invisible sub-structure tasks became visible to the client and were considered part of the deliverables. Expectations moved with reality.
Over time, I implemented a web-based tool which allowed me to quickly dissect a project into tasks and to update the list of tasks with a minimum of effort. In certain situations, I provided the client with access to this task list so he could see exactly what was and was not done at any given point. I'm still working on this tool to provide a summary capability so clients can see, with a single glance, where projects stand.
Learning to plan, and to update plans regularly, requires a lot of discipline and support. I've found that most programmers don't stick with it unless they are regularly coached and supported until the planning process becomes a habit. Convenient tools make the process of forming this habit a lot faster and easier.
When I explained my planning technique to my associates, they laughed and said that their web application project would probably have gone an entirely different way if they had taken my approach. When I took them through the paces of dissecting one of their current projects into a task list, I could see the spark of insight in their eyes which told me they understood this type of planning is essential for the success of any project.
posted by John Keklak at
10:39 AM
0 Comments:
Post a Comment
<< Home