15 percent of the resources dedicated to Chicago or 85 percent of the resources on Office96. See what we did there.—Resource allocation for the parallel releases, as marketed internally
"Picking dates with resource levels set is the first rule of shipping." This philosophy was novel at the time. Much later on a book was written by Ram Charan and Larry Bossidy named"Execution" which laid out the need to align resources with strategic priorities. That is exactly what this philosophy did.
It is also interesting to think about time as another dimension of resources. Once the ship date is set laying out the engineering work in ever more specific iterations is required to arrive at a project that can execute on its expectations. The first level of iteration was defining a set of engineering milestones followed by integration and stabilization periods. Working recursively, milestones themselves were a set of features followed integration and stabilization. An individual feature was a set of tasks followed by integration and stabilization. For the schedule to be believable, tasks had to have a single developer and last no more than two days. When planning, all features were recursively subdivided until this standard was met.
In today's jargon, the schedule became a work or burn-down list sorted by priority of task and feature with estimates allowing the team to know roughly what tasks would be complete in what period of time. The development leads of each feature team were responsible for standing up their teams once a week to check off work completed and update estimates based on learning. This allowed the schedule to become more accurate as time went by as the team learned and technical issues were identified.
It is confidence in the above planning and execution framework that allowed us to think we could get away with something as audacious as 12/24.
There was always out of the box thinking/pressure from BillG and NathanM for the 48/60 work as well. We understood this but were never confident we could do it. But sometimes things were engineered that way. 32 bit support is a good example, where app teams had a couple developers outside of the execution framework of Office 4.x porting the 16 bit code to 32 bits, identifying the problem areas, and building toolsets that could then be leveraged more broadly. That was critical work that enabled Office 95's team. It was the learning from these folks about the challenges of 32 bit app performance that contributed to the 12/24 thinking. Some of the performance work just couldn't be done on the Chicago timeframe. It wasn't the major reason for 12/24, but it was one part.
The first 32 bit Office (just XL and Word) was Office for Windows NT was released before Office 95 (Intel, DEC Alpha, MIPS, and Power PC versions if my memory is correct) which made the 94/96 releases easier. At least is was mostly 32 for Excel. DuaneC could go into the details around the recalc engine.
As for the Windows Logo, I seem to remember a GPM saying that, "What the Windows team doesn't understand is that we (Office) are the Windows Logo." :)
By fortunate coincidence, as you have been writing these I have been teaching summer classes on C++ and Microsoft Office at a local community college. If you do not have any objection, I would like to send my students a link to read this entry and also #10 (Our First BillG Review) as I think these two entries will reinforce some concepts I have been trying to bring to them -- particularly the messy evolution of C++, OOPaholism, and the joys of binary files (last class we did a hex dump of a xls).
"Picking dates with resource levels set is the first rule of shipping." This philosophy was novel at the time. Much later on a book was written by Ram Charan and Larry Bossidy named"Execution" which laid out the need to align resources with strategic priorities. That is exactly what this philosophy did.
It is also interesting to think about time as another dimension of resources. Once the ship date is set laying out the engineering work in ever more specific iterations is required to arrive at a project that can execute on its expectations. The first level of iteration was defining a set of engineering milestones followed by integration and stabilization periods. Working recursively, milestones themselves were a set of features followed integration and stabilization. An individual feature was a set of tasks followed by integration and stabilization. For the schedule to be believable, tasks had to have a single developer and last no more than two days. When planning, all features were recursively subdivided until this standard was met.
In today's jargon, the schedule became a work or burn-down list sorted by priority of task and feature with estimates allowing the team to know roughly what tasks would be complete in what period of time. The development leads of each feature team were responsible for standing up their teams once a week to check off work completed and update estimates based on learning. This allowed the schedule to become more accurate as time went by as the team learned and technical issues were identified.
It is confidence in the above planning and execution framework that allowed us to think we could get away with something as audacious as 12/24.
There was always out of the box thinking/pressure from BillG and NathanM for the 48/60 work as well. We understood this but were never confident we could do it. But sometimes things were engineered that way. 32 bit support is a good example, where app teams had a couple developers outside of the execution framework of Office 4.x porting the 16 bit code to 32 bits, identifying the problem areas, and building toolsets that could then be leveraged more broadly. That was critical work that enabled Office 95's team. It was the learning from these folks about the challenges of 32 bit app performance that contributed to the 12/24 thinking. Some of the performance work just couldn't be done on the Chicago timeframe. It wasn't the major reason for 12/24, but it was one part.
The first 32 bit Office (just XL and Word) was Office for Windows NT was released before Office 95 (Intel, DEC Alpha, MIPS, and Power PC versions if my memory is correct) which made the 94/96 releases easier. At least is was mostly 32 for Excel. DuaneC could go into the details around the recalc engine.
As for the Windows Logo, I seem to remember a GPM saying that, "What the Windows team doesn't understand is that we (Office) are the Windows Logo." :)
By fortunate coincidence, as you have been writing these I have been teaching summer classes on C++ and Microsoft Office at a local community college. If you do not have any objection, I would like to send my students a link to read this entry and also #10 (Our First BillG Review) as I think these two entries will reinforce some concepts I have been trying to bring to them -- particularly the messy evolution of C++, OOPaholism, and the joys of binary files (last class we did a hex dump of a xls).