<= /o:p>

The Matrix is basically our term for a quick and dirty process for coming up wi= th a proposal cost and schedule. Later, this matrix evolves to also be the matrix through which the developers communicate with the PM how long a given specification will take to complete.

The Matrix is not the same as a Microsoft Project document. Microsoft Project entails a lot of overhead and assumes an already specified schedule, mandays and resource allocation. The matrix is both simpler and more complex than Project.

Simpler Than Microsoft Project

The matrix is simpler than Microsoft Project because i= t does not take into account dependencies. It also does not take into account more than one resource being added. It usually assumes a single developer workin= g at any given time serially on all items.

This simplification makes the process of manipulating = the matrix less cumbersome and easier to work with than Microsoft Project and i= s an important point. Spreadsheets were invented specifically to accommodate “What-If” scenarios, and likewise, the matrix is for manipulati= ng what happens when things are added and removed from a spec. Microsoft Proje= ct does not excel at “What-If” scenarios – it manages an alr= eady laid out scenario of what the client said they specifically wanted.

More Features Than Microsoft Project

Just as The Matrix is simpler than Project in some way= s, The Matrix is also more complex than Microsoft Project in other ways. This is because the Matrix doesn’t just take into account number of days.

The Matrix also serves as a worksheet that takes into account project complexity so that an appropriate man-day multiplier may be applied. It also takes into account schedule days as well as man-days in ca= se there is a difference in how a scheduler needs to enter the project –= by schedule day instead of just man-days. Note that scheduled days means how l= ong something really takes. For example, a project may take 2 man-days whilst g= oing through specification approval process, but 5 real scheduled days for the client to mull it over completely and sign it off. The matrix also makes notes/further description of the task more obvious as it gets entered for e= ach line item if necessary.

Why We Use The Matrix

We use the Matrix because without it we are blind. The amount of time resources spend on a project is how we make our money. If we= do not control the resources, we will have no way of recognizing whether we are under or overcharging the client and whether the schedule is under or overestimated.

Project Control

Overcharging the client is a sin and will cause the cl= ient to leave us eventually.

Undercharging will cause us to run out of money that c= ould be spent in the best case on bonuses and at the very least on R&D to further our company.

Overestimating the time of the project will cause us t= o lose control over what an employee is doing and we won’t able able to sche= dule them for R&D or another task except in a reactionary way when it is fin= ally discovered that the developer is idle.

Underestimating the time of the project will cause embarrassment to both the_company and to our client if a project is not delivered on time.

All are risks we must avoid. The Matrix is there to pr= ovide a reasonable tool that takes little time to develop (no more than a few hou= rs usually) in order to come up with a reasonable estimate of how long a proje= ct will take and from there the cost of the project can be determined.

Good Client Relationship

Furthermore, any time the client wishes to ask “= How come the project costs this much?” we can easily show and go through = the matrix with them to explain exactly why these are reasonable timeframes and costs.

The Matrix also helps to avoid misunderstanding about = the complexity or the amount of time that will be put into certain parts of the project. For example, a proposal might say we are providing documentation. = But what does this mean? Documentation can be a few pages or it can be a few hundred pages on the same program depending on how detailed you go.

If you build a matrix and explain it to the client tha= t we are providing 3-days worth of a document, then the client will know not to expect a tome, but neither will they want a 2-page FAQ. The matrix and subsequent schedule help the client understand the level of effort at each stage of completing something in a functional specification.

Matrix Example

The following example shows a matrix that we would com= e up with for the Java Web Calendar if it needed to be done from scratch.

Name	Estimated Man-Days	Complexity	Multiplied Man-Days	Scheduled Days	Notes/ Description
Specs	5	1	5	5	Assume no timezone logic
Specs Approval	2	1	2	5	Assumes a week will be taken for approval cycle, even if 2 man-days of work<= /o:p>
Detailed Design Document	2	1	2	2
Detailed Design Document Approval	1	1	1	1	Internal design review
L&F Concept	2	1	2	L&F
L&F Concept Approval	2	1	2	5, L&F	Assumes a week will be taken for approval cycle, even if 2 man-days of work<= /o:p>
L&F Views (5)	5	1	5	L&F
Create App Structure	1	1	1	1
LoadDateRangeAction	2	1.5	3	3