<= /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	Complexity higher due to being a load action for all views generically
MonthViewLogic	1	1	1	1
MonthViewJSP	1	2	2	2	Complexity higher due to futzing with HTML generation of calendar object<= /span>
DayViewLogic	1	1	1	1
DayViewJSP	1	2	2	2	See notes for Month View. Day View has added complexity due to ‘blocking algorithm’
EditEventLogic	1	1	1	1
EditEventJSP	1	1	1	1
DeleteEventLogic (No JSP)	1	1	1	1
AddEventLogic	1	1	1	1
AddEventJSP	1	1	1	1
Confirm Add/Edit/Delete	1	1	1	1	Easy, little functionality
Support Documentation	2	1	2	2
UAT Test Plan	2	1	2	PM
Reminder Cron Job	3	1.5	4.5	4.5
Generic DB SQL/Schema	1	1.5	1.5	1.5
Unit Testing	5	1	5	Partial Time Overlap with PM
SIT	1	1	1	1
UAT	5	1	5	5
Go-Live	1	1	1	1
Total			57

Matrix Explanation

As you can see from the example, the matrix itself is = more like a worksheet than a project plan. This is an important distinction. Pro= ject plans are not meant to be what-if scenario builders. Generally it is meant = to track the progress of a project and occasionally change the timelines when something changes in the plan in the course of a project.

The matrix is meant to be more fluid and capable of allowing the developer to t= hink “how can I produce this app in the least amount of time while still remaining true to the specs”. In other words, it helps us prov= ide the client the best value for the money. This is accomplished because the Matrix follows a flexible spreadsheet/worksheet motif. Typically we do the matrix using Microsoft Excel.

Matrix Structure

The structure of the matrix is basically a header, tas= ks to perform roughly laid out in time order (but not necessarily), and a final t= otal at the end. Each column for each task services a specific purpose.

Task Breakdown

The rule of thumb for task break down is that a given task should take less tha= n a week. If a task takes more than a week, it generally should be broken down further. Exceptions include specs and UAT time. But the raw logic of t= he application should be 1-3 day tasks.

This granularity makes sure that there is nothing that= is forgotten that might result in days of overrun. Note that sometimes it is not possible to provide suc= h a tiny granularity ahead of time such as early in the proposal cycle. This sh= ould be a red flag to sales that they need to get more information from the clie= nt.

Man-Days

Man-days is the amount of man-days you believe it woul= d take for a task to be accomplished under normal circumstances. We shall see that this field plus complexity is used to come up with the actual man-days.

Complexity

The complexity multiplier is basically a means of trac= king how sure a developer is that their man-days calculation is correct. It serv= es as a kind of reminder to a developer that they should always consider the complexity of a project when giving the client a timeline.

Most of the time, the complexity multiplier will be 1,= which multiplied against the man-days yields the original man-days.

Adding complexity into cost and time estimates is not = a new idea. The major model for this is called COCOMO (Constructive Cost Modeling) and was introduced by Dr. Barry Boehm in 1981. More can be found about the current state of COCOMO at the following URL: http://sunset.usc.edu/res= earch/COCOMOII/.

COCOMO is much more complex than our simple complexity multiplier, but we recommend every the_company developer read the research behind COCOMO to understand how to consider adjusting the complexity multiplier. The following URL illustrates the intermediate level COC= OMO using a web-based multiplier: http://sunset.usc.edu/research/COCOMOII/cocomo81_pgm/cocomo81.html.

The following bullet points represent items to take in= to account when deciding complexity and covers Product, Computer, Personnel, a= nd Project attributes:

*&nb= sp; Required Reliability

*&nb= sp; Database Size

*&nb= sp; Product Complexity

*&nb= sp; Execution Time Constraint

*&nb= sp; Main Storage Constraint

*&nb= sp; Virtual Machine Volatility

*&nb= sp; Computer Turnaround Time

*&nb= sp; Analyst Capability

*&nb= sp; Applications Experience

*&nb= sp; Programmer Capability

*&nb= sp; Virtual Machine Experience

*&nb= sp; Programming Language Experience

*&nb= sp; Modern (Good) Programming Practices

*&nb= sp; Use of Software Tools

*&nb= sp; Required Development Schedule

You may ask yourself, why don’t we just use COCO= MO? We could. However, COCOMO is fairly rigid and is generally useful on larger projects where the added complexity of a detailed model is more useful.

Because we are a web-based company and have many years= of experience with web-based applications, much of our estimates tend to basic= ally fall into place based on rules of thumb related to how web-based application life cycle tends to be created. In other words, our matrixes are already pre-COCOMOized because we have a great deal of experience in the area of web programming.

Multiplied Man-Days

This figure represents the true man-days a project sho= uld take to complete and is calculated simply by multiplying the complexity col= umn by the man-days column.

Scheduled Days

This is not a strictly numeric column. But it is usefu= l to communicate additional information to a PM or to the proposal author who is figuring out cost to tell the client. There are two main uses for this column in almost every project: parallel work, and client waiting time.

Scheduled days are also meant to communicate who the w= ork is affecting if it is not directly affecting the technical team. For example, L&F work may only affect the L&F team waiting for it to complete. Likewise, work that a PM may provide such as writing a test plan may not be days that are scheduled for a developer.

This extra information is important because it allows = the PM to figure out what work can be done in parallel and which cannot.

Scheduled Days Parallel Work

Some of the project work can be done in parallel with = the developer, so it is useful to provide a hint to the Project Manager that a given section may be done by another group when the PM finally puts this in= to Microsoft Project.

For example, the graphics group might do look-and-feel= while UAT Test Plan might be written by the PM herself. Adding the note “L&F” in the scheduled days column for the look-and-feel wh= ile the UAT Test Plan scheduled days column has “PM” added to it in order to indicate these time allocations.

Scheduled Days Client Waiting Time

Another issue in project times is waiting on the clien= t. We should generally schedule based on client past history or what the client believes is a reasonable timeframe to approve of specs, look-and-feel, and other documents.

This does not mean the client will necessarily pay for= the entire approval cycle time, but as long as it is schedule it is useful to figure out how else to deploy our resource during that period. Possibly, th= is would mean programming ahead of the approval cycle.

Notes/Description

Further notes to let the PM or proposal author underst= and the motivation behind complexities, man-days, or schedule days.

Totals and Matrix Interpretation

The actual interpretation of the matrix is open depend= ing on who is looking at it. Usually the first matrix is seen by a proposal author= who is looking at figuring out a cost for the client and a rough idea of schedu= le. So the most important figure is the total man-day figure and the schedule t= hat is provided typically will err on the longer side.

Then, the PM when looking at matrix will generally cre= ate a more detailed schedule based matrix and isn’t concerned as much by co= st. Some basic issues involve how many developers would reduce the timeline of = the project. For example, earlier we stated that the matrix is written as if it= is one developer doing the work. However, many clients prefer time to market a= nd are willing to pay for two or more developers on a compressed project. It is sometimes useful for the matrix developer to include the estimated cost of having 2 developers work on a project. Generally, adding a developer to a 1-developer project as a rule of thumb will halve the time it takes plus 1 = week for every 4-8 weeks of work because of communication and integration issues between both programmers work depending on the complexity of the project and how much the technical work done in parallel overlaps.

Matrix interpretation and costing is the subject of another SOP that is written by= XXX, COO of the_company.

Matrix Rules of Thumb

Given the extensive experience the_company has develop= ing web-based projects, there are many rules of thumb we’ve developed that make writing matrices easier and easier.

Matrix Must-Haves

Matrix Must-Haves are basically items that you should = see on every matrix with very little exception. These include the following:

*&nb= sp; Specs

*&nb= sp; Specs Approval Time

*&nb= sp; Look and Feel (L&F)

*&nb= sp; L&F Approval Time

*&nb= sp; SIT (System Integration Test)

*&nb= sp; UAT (User Acceptance Test)

*&nb= sp; Writing the TestPlan

*&nb= sp; Internal or Unit Testing

*&nb= sp; Views separated from Program Logic (Actions)=

Sample Timelines

The following table outlines sample timeline rules of = thumb for various items you will commonly see on an the_company matrix.

Name	Sample Timeline
Specs	5 man-days for every 6-8 weeks project unless the pr= oject is more complex
Specs Approval	2 days for ever 5 days of original spec time, 5 sche= duled days for every 5 days of original spec time
Look and Feel	5 man-days for every 6-8 week project. Generally you should break out 2 days for initial look-and-feel and a day for every maj= or view in the application.
Look and Feel approval	Same rules as specs approval
Database Schema	1 day for every 5 tables
Each major action	1 day for each major action (will also include model creation)
Each major view action	1 day
Each JSP/TTML page	1 day
UAT	Minimum 5 days, should be 5 days per 4-6 week time p= eriod
SIT	Minimum 2 days in first phase, subsequent phases can= be less if no more integration complexity
Go-Live	1 day given successful UAT
Support Document	2 days for every 5 days of specs for simple support,= for complex support 10 days for every 5 days of specs. Most clients prefer le= ast cost support document.
UAT TestPlan	2 days for every 5 days of UAT
Internal/Unit Testing	Prior to UAT, done by same amount of time as UAT but internal to the_company

Things Not To Forget

The worst thing that can happen to a matrix is that something is left off. Since each item on a matrix takes 1-3 days to produce, leaving off one item= can lose us thousands of dollars on a project plus possible schedule overrun.

Therefore, you should strive to make sure you remember everything that needs to go into the matrix. Some things you should always = do to make sure the matrix is solid:

*&nb= sp; Read the proposal or spec over again and map each item to a matrix task. If it doesn’t exist, then you’ve forgotten somethi= ng

*&nb= sp; If a particular task is complex, consider breaking the complex item out into subtasks of what it would take to develop it. You might surprise yourself and find that breaking it down further reve= als more items that need to be done to perform that task

*&nb= sp; Always, always, always ask another programmer’s opinion. You will almost always forget one task that a second programmer will not forget. An hour of meeting with a second developer can save a day to three = days of programming time.

Proposal Matrix versus Project Matrix

The matrix that is written for a proposal is by necess= ity different from a project matrix. A proposal matrix must be extensible yet m= eet the minimum requirements of the proposal for the client. The project matrix should be as detailed as possible to provide much more accurate scheduling.=

In other words, the proposal matrix emphasizes cost, while the project matrix emphasizes accurate schedules. The difference is subtle so some matr= ixes won’t see any change, but generally the project matrix is more detail= ed than the proposal matrix as it is based on having written specs.

Proposal Matrix

The proposal matrix should be as accurate as possible.= If a developer cannot write a reasonable proposal matrix based on the proposal t= he_company writes, then it is likely that this project is a high risk and should be red-flagged to management as to why we are submitting the proposal without a matrix.

The main rule of thumb for the proposal matrix is that it must be written in su= ch a way that it is minimal yet extensible. Minimal not in terms of forgetting items that are important to include but minimal in the sense tha= t we cannot know everything at proposal time or each proposal would require full specs gathering.

The proposal matrix should not cheat the client. The r= eason it is minimal is because the specs are minimal – they are proposal-le= vel specs. And indeed, the matrix is something that will in many cases be revea= led to the client when they want to make sure we understand their needs (see Cl= ient Relationship Management section of this SOP).

The proposal matrix should be extensible not rewritable. Ideally,= no item on the proposal matrix should ever be removed after specs are gathered= . Instead, the items should = be written in such a way that if specs gathering changes the scope of the prop= osal that additional line items are added instead of changed.

This is extremely important. Scope creep is something = that the client has hired us at a fixed cost to control. Therefore, we must alwa= ys be able to, as much as possible, highlight scope creep by adding items to t= he spreadsheet and comparing it against all the original items that existed at= the start of the proposal. The client will always think of new things to add throughout the life cycle.

This is just how a project lifecycle works as RFPs are= never ultra detailed, and so we need to help the client identify and control extra scope in order to deliver the project on-time and in-cost. If the client wi= shes to add an item, it will be very clear that it is an additional item.

Project Matrix

The project matrix, as mentioned before is more detail= ed than the proposal matrix. Again, we restate that as much as possible new items should be added to the matrix without removing or changing original tasks t= hat were listed. A * sho= uld be placed next to the name of all new items so that it is very clear where the matrix started from and what is new.

Client Relationship Management

The matrix can be used as a useful client relationship management tool. Client relationships are built on trust. If you tell a client a project will take a month, you should be prepared to back that up by showing the client everything that goes into a project.

Further, sometimes clients do not have an idea that projects take as long as they do= . They require explanation and training in this area and this is part of our value-add as experienced professionals.

If they have an in-house IT department, they are used = to dealing with IT group that knows their business and infrastructure so frequently creating a small program for an internal IT group is very fast a= nd quick and little documentation is done. When outsourcing to a third party, documentation and project management becomes crucial to managing the relationship and the communication and transfer of knowledge on both sides.=

If they have no in-house IT department, they are usual= ly not technical clients and therefore they do not realize what the life cycle of a project is. They do not understand all the items that a programmer or sysad= min must do to create a project. They may not understand how to perform a UAT because they have never bought or used software more complex than off the s= helf apps such as Microsoft Office.

Don’t Force the Matrix

With that said, you should not force the matrix. Some clients are much more business focused and they prefer not dealing in detai= ls. However, the matrix should be offered in case the client wishes to know what the life cycle is.

In any case, even if the client doesn’t want to = see the technical details, then the sales person should still present the matrix but as a watered down version which maps proposal line items and stuff like= UAT (which the must be taught to understand anyway) to man-days.

If in Doubt, Show The Matrix

If you aren’t sure if a client will appreciate t= he matrix and they aren’t sure, show it to them. You can always simplify= it for them by grouping technical subjects together if they find it too low-le= vel. But in any case, just simply providing a medium around which to talk concre= tely about costs and schedules will improve your trust relationship with the cli= ent because they’ll know you haven’t just pulleed figures out of the air.

Don’t Blow Up The Matrix

Never blow up the matrix unnecessarily. More on this subject will be part of the Specification Gathering SOP written by Gunther Birznieks.

By blowing up the matrix, we mean that in the proposal stage, the matrix represented a cost and timeline to the project. If, after only a week or t= wo of specs, the matrix blows up to 30% or some outrageously high cost/time delay, then the specs gathering process has not done it’s job or the matrix = was done poorly in the proposal writing stage.

The specs gathering process is not a requirements gath= ering process. Requirements were laid out in the proposal. It is then our job to basically spec out how to satisfy the requirements within the timeline outl= ined in the proposal.

No additional items or requirements should be added un= less they are truly additional works or unless we, as experts, failed in some wa= y to identify the extra work in the proposal (ie our fault). If the later we will absorb the cost, but generally the client should be responsible for understanding the proposal (as we go over it with them thoroughly) and know that if they add requirements that require more specification, they will en= d up assuming the cost.

END