More Related Content
What's hot (20)
Similar to Project_Estimation (20)
Project_Estimation
- 1. ProjectEstimation Naeem Bari Director IT CEQUEL III [email protected] [email protected] 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.