1. ProjectEstimation
Naeem Bari
Director IT
CEQUEL III
Naeem.bari@cequel3.com
Naeem@cyweb.com
Summary
Project Management 101: This talk introduced you to the fundamentals of project
management. Estimating costs, timeline, putting together a project plan and a team.
Also includes an intro to server sizing that some may find useful.
Scenario
You have just been asked by the CIO and the CFO to build a new website that will
handle purchase requests for your company. The CxOs outline (very sketchily) the
tasks that this new system is expected to perform. Lots of hand waving involved.
On-line… mumble mumble… easy to use… mumble mumble… integrate with
accounting system… blah blah… scalable, fault tolerant etc etc. After the hand
waving they look you squarely in the eye and ask – “so how much will this cost
and how long will this take?”
Congratulations, you are a project manager.
The Initial Response
Never give an estimate of the ETA and costimmediately. Whatever you say will be
wrong – guaranteed. Instead, ask the following questions:
Why do we need a new purchasing system? What is it replacing? Why is the old
system inadequate?
Why does it need to be online?
Who is the project sponsor?This is the personwho will acceptwhat you
deliver, authorize payments etc. The CFO, most likely.
Who is the primary user? This is an important question. More so than who is
the project sponsor. This is the personwho will be the highest ranking day to
day operational user of the application. This will rarely be the CFO. More
than likely it will be some direct report of the CFO – maybe a controller,
maybe a purchasing director. This person can make or break your project.
The CFO will do what this person recommends. This is the person who will
help you gather requirements for the application, identify users, help with
the design and help with testing.

2. Can we buy vs. build? This question usually has a more straightforward answer
than one would think. This can be answered by determining how much
money the sponsoris willing to spend if we can buy an OTS solution.
Explain that apart from the purchase cost, they also have to budget for
implementation, which can be quite costly. More often than not, you pay
more money for a packaged solution but you get more functionality. If your
sponsorsdon’thave the money or don’trequire the functionality, then it
might be better to build.
Is there a constraint on when this application needs to be completed? End of the
budget year? End of the quarter? The sponsorprobablyhas some pre-
conceived notion of when the application needs to be available. If a deadline
is provided, ask the obvious follow up questions:
Why the deadline?
What will be the impact if we can’t make the deadline?
This is a difficult line of questioning, but one that needs to be conducted. It
is usually easier to determine when you won’t be able to make a deadline
than to determine when you will be able to meet one. It is way better to
manage expectations up front than to have to do damage control later.
Once this initial line of questioning is complete, clarify your role to the CxOs,
outline your next steps, outline your approachand explain your expectations from
them. Bullet points express it best:
Explain that your role will be that of the project manager. You may also
participate in the development, depending on the size of the team that you
will need (and that you will communicate the estimated budget and team
size once you have put together the first draft of the project plan).
Explain to them that your next steps are to:
Have a detailed discussionwith the primary user.
Draft a 5,000 footlevel functional requirements document within a week
at most.
Have the sponsorand primary user approvethe document – or at least
nod their heads.
Develop the project plan that you will follow.
Outline how you perceive the project to be implemented. Tell them that after
the requirements have been gathered, the project plan and budget has been
approved and the team has been assembled, you will implement the
application in an incremental fashion, with pieces of the application coming
online at various milestones (this is usually the best way to go, if possible –
the traditional watershed approachrequires the customer to wait too long

3. before seeing anything – and it smacks too much of the recently deceased
$200/hr dotcom days ).
Explain to them that you expect a level of cooperation from them. Probably
weekly meetings to begin with, then switching over to as needed. They also
need to commit to helping you convince the users to buy into the
application. This requires them to be excited about this project, and to
project that level of excitement to their staff as well. Change is hard, and
users don’tlike it unless they are excited by what you are doing – or are
forced by their bosses. Either way, the CxOs need to be the point people for
this.
It is important that your superiors realize that you have a concrete plan of action,
and that you will immediately start working on items that will contribute to getting
the project rolling. This is an important point. All too often a project will stagnate
after the initial meeting because the supposedprojectmanager is not really sure of
what to do next. Inevitably, after a few weeks have gone by, the senior
management will have to get involved again – and that will leave a bad impression.
You have to be the driver. Once you have received the blessing of your CxOs, they
need to be comfortable knowing that they have entrusted a high profile project to
someone who can deliver.
Technology Selection
Ok, you talked in detail with the primary user, got his buy in (very important) into
this project and got the functional requirements document done and approved.
Beautiful! But before you dive into the project plan, you need to select the
technology that you will use. This can have an impact on the plan. Do you use PHP
or do you use Java? Coldfusion or Dreamweaver? Both? J2EE or .NET? Unix or
Windows? Solaris or Linux? Obviously, in a lot of companies, these questions
have already been answered and you have to follow the standards. Doesn’t mean
that you can’t be creative, however. Forinstance, even if J2EE is mandated, do you
need to use EJBs or can you get away with a connection-poolenabled servlet based
framework? JSPs or servlets wrapped around Velocity? Oracle or MySQL?
Once the language, database and OS has been determined, the next question is:
how much hardware do you need? Can you make do with one single cpu server or
do you need a n-tier hardware solution – high powered database server, mid level
app server and dinky web server? Does the web server go into the DMZ or not? Do
you connectthe app server and the database server on an isolated network
segment? Enter the wonderful world of Server Sizing and Network Architecture.

4. ServerSizing & Network Architecture
Now, this topic is not really an integral part of this presentation. However, this is a
skill that all project managers should have, and very few do. So we will address it
(Note that if you do not know what a DMZ is, you should get someone to assist
you in at least the network design). Lets start by assuming that we are talking about
a decent sized application requiring a n-tier architecture. We make this assumption
because this is the most difficult application to size for.
Some useful points are:
The thumb-in-the-air, “lets buy a 4-way database, application and web server”
is not a viable strategy.
In a well-designed OLTP application, it’s the database server that bears the
brunt of the work. The application server works less, and the web server
mostly twiddles its thumbs (Note that this is generally not true for packaged
solutions – most packaged solutions have a highly normalized database
structure and they also do transaction management at the application level
since they can’t rely on the nature of the underlying database – this means
that they generally require a powerful database server and an even more
powerful application server).
If this application will be accessible over the web to the external world, then
you need a DMZ, and your web server needs to sit in the DMZ.
Application and database servers should never be in the DMZ.
The application and database servers generally have a lot of network traffic
between them. You can address the inevitable “why is the system so slow”
problems in two ways:
Put the application server and the database server on their own switch OR
Buy dual Gigabit NICs for both servers. Connect the 2 servers directly
with a crossover cable using one set of NICs and use the other NIC for
normal network traffic.
So how do you size the servers? Follow this path:
Determine the peak number of users by questioning the primary user:
How many users will be on the system at peak time?
A. Don’t know.
Q. How many total users?
A. Uh, 500 or so total users.
Q. When do you expect the busiest time to be?

5. A. Probably end of the budget year, everybody will be trying to get their
purchase requests in.
Q. How many requests did you get with the old system, over how many
days?
A. We got about two thousand requests over a week! Why, one day alone we
got more than 500!
Ding ding ding! Breakthrough! So now we know that historically the peak usage
was 500 requests in a day. To get our final figure, we should assume that all that
usage was during one hour (500 requests/hr), treble it for good luck (well, to allow
for growth and accountfor transaction requests other than creating a purchase
request), and start our sizing calculations from there. So this gives us roughly 30
requests per minute. Now, each request can result in more than one transaction (for
example, creating a purchase request might involve – get list of vendors, get list of
parts for vendor, create purchase request, create n line items etc). You have to use
your best estimate for the average transactions/request and multiply it. For
example, assuming an average of 5 transactions per request, we get our estimated
requirement of 150 transactions per minute.
Now that the tpm number is known, you can use the TPC’s tpcC benchmarks to
look for an appropriate database server. For our example application you will see
that you need the horsepower of about your average wristwatch . Seriously, such
a result would tell me that we could make do with a single cpu 1U database server.
Given our previous assertion of relative horsepower, it stands to reason we would
need even smaller configurations for the application and web servers. Keep in
mind that you may have other constraints, like failover, that will govern your final
hardware choices. But at least you would be at the point where you would know
how much hardware you really need, then leverage some provider’s expertise in
building the closest fault tolerant system. This will minimize the investment in
hardware and make your boss happy.
ProjectPlan
Now that all the pre-requisites are out of the way, we can get down to the serious
business of determining the number and type of resources we need and the project
timeline.
First create the shell of a project plan, with the following phases:
Requirements
Design

6. Database design and creation
Data load
Framework design and creation
Development
Design, develop and test function 1
Design, develop and test function 2
Design, develop and test function 3
…
System Test
Implementation
You can probably see that this is slightly different than a standard watershed plan:
The design phase gets the database model implemented and populated early on.
It will be revised as the project progresses, but you a good basis on which to
start development.
The design phase also has the creation of a framework. This framework will
most likely be some “enabling” codethat will allow you to write business
level functionality without having to worry about the technical details too
much. Forinstance, if the language was Java, we could deploy Struts or
some other framework at this point.
The development phase is completely iterative, with individual pieces
functionality being designed and built.
With this approach, oncethe project is in its development phase, there will always
be something new to demo each week. This is perfect for making sure that the
project is heading down the right path at all times, as well as garnering accolades
for your capable handling of this critical project .
Once the tasks are all filled out, attach resources to them and estimate the duration.
Group related tasks together, so a single personcould potentially complete a
section of the application. Keep track of dependencies. Once the plan is filled out,
then you can look for areas where you could save time by bringing on additional
resources.
You now have a 5,000 foot level requirements document, the language, database
and OS selection, the server sizing study and selection, the network design and the
project plan. You know how long it will take, how many resources you will need
and how much it will cost. All the above steps should not take more than 2 weeks.

7. Now is a good time to have another meeting with the sponsor(s).Present your
findings. It is important to clearly articulate to them that the numbers are all what
you feel comfortable with, but that they are estimates. If the requirements change,
you will gladly accommodatethe changes, and you will let the sponsorknow of the
impact on the costand timeline.
Notes
Some advice on team selection:
A smart developer is one who loves writing code, and can adjust to writing
good codein any language, whether its PHP, ASP, C++ or Java.
Sometimes a programmer who has excelled in a language different from your
chosen one may still be a good choice. For instance, I prefer a developer
with several years of C/C++ experience over a developer who has several
years of Java experience only. The C++ developer has been through fire and
survived. Java is easy by comparison. For the same reason I prefer a Java
developer to a Visual Basic developer. Doesn’t mean this theory always
works – its just a hint to keep in mind.
One smart developer is better than 3 average developers.
Do not even consider a less than above average developer.
Pay more for fewer, good resources. Your project will be staffed better,
management will be easier and it will have better chances of being done
right!
Get the best DBA you can afford.
If your team size is getting larger than 4, you will need a team leader reporting
to you, who will take charge of a portion of the project.