A project phase is made up of activities, each of which is accomplished by the completion of one or more tasks associated with that activity.
When you have some of the actual users who are going to utilize the system do some testing at or near the project deliverable's completion, you're involved in user acceptance testing (UAT). UAT is valuable, not so much from an overall "how does the system perform?" standpoint but from the user's perspective of how well the system meets his or her needs. Both assessments are valid and required, but UAT gives you a feel for how close you got to the target with your customer.
Sequencing of activities is like choreographing a dance. The dancers have to be in the right place at the right time, and they have to know their steps. Just so with your project's team members. You have to sequence the steps of your tasks so that they are accomplished in the order that most makes sense and so there are no delays in time while team members are forced to wait for someone else's task to finish to they can carry on with theirs. Too much inaccurate sequencing could lead to missing the project's deadline.
Linear regression is the statistical term given to the measurement of two unlike variables, one of which may have a direct bearing on the other. Parametric cost estimating utilizes linear regression techniques, though it is a more sophisticated cost estimating method, utilizing other features as well.
The idea with top-down is that a competitor has a product you'd like to emulate (because there are a lot of bucks in the sale of this product). In order to try to develop the same product and undercut your competitor, you opt to use the top-down method. You take your competitor's unit price, subtract out a profit figure, then set up your project in such a way that you meet the remaining per-unit price. The difficulty lies in the balancing of the triune constraints: time, budget, quality.
While it's important that you communicate from time to time with the executive project sponsor and the stakeholders, it is not necessary for their calendars to be integrated into your project calendar. It is important for your team members' calendars and the company's calendar of its official holidays and business meetings to be introduced into your project calendar. Fortunately, today's e-mail systems utilize calendar-sharing, which makes your project calendar work
much easier. C
You can opt to track a project by the stipulated requirements. Because each requirement has associated with it a metric that denotes the success of the achievement of a requirement, this method yields requirements completion-oriented results. All methods are valid; you pick one depending on the most important concerns that you and the stakeholders/sponsors have relative to the project.
Individual team members are responsible for the development of the cost estimates for the tasks they' ve been assigned. The reason for this revolves around the fact that they are the SMEs who understand the task before them and can best assess the costs associated with a task. However, caution each team member to use average costs when tallying cost estimates. Individuals may not have average salary information, and you may have to supply this information.
Generally, IT projects aren' t launched in order to provide a product or service that will be sold to customers (though the standard IT project will probably be used to augment customer satisfaction or to lure in more customers). With other methods, you' re typically oriented toward the feeling of manufacturing or building—you' re concerned about making something that compares to standard per unit costs. By the time an IT project is being seriously discussed, the implication is that the outcome is extremely beneficial to the company. Now it ' s a matter of keeping costs down by managing them effectively, and the bottom-up cost estimating model helps accomplish this.
Technicians are the best choice to manage architectural choices because they ' re close to the technology and understand how the complexity and nuances of the
architecture chosen. Folks in other groups may have a pretty good idea about IT, but the technicians are the SMEs when it comes to architectural considerations.
The Gantt chart is in the right pane of the exhibit shown. Milestones are denoted in this particular software by a black diamond and include the projected milestone date.
Looking at the Gantt chart, you can see that the normal long bar that represents a task is replaced by the black diamond. The tasks ' durations don' t change, but the appearance of the object in the Gantt chart changes to reflect that a given task represents a milestone. In this case, the two tasks are Activity 1, Task 3 and Activity 2, Task 2.
Cost estimating isn't budgeting. For starters, you' re probably not the one who will do the majority of the formal budgeting for the project (although you may keep a budget spreadsheet that details your expenditures and the time worked by team members). The budget is a formal document that' s kept by the company' s financial folks. Cost estimating, though, is an input to budgeting. Cost estimating also has a direct bearing on the team member selection that you make, because team members assist you in cost estimate formulation. This sounds circular, because it is. If you have a weak team member working on a task, the cost estimate is going to be higher because his time estimates are going to be higher, driving up the cost of the task.
Chances are, with a limited budget, you ' l l try to whittle down the task durations to their bare minimums. You' l l also likely not pick the same staff that you' d pick if money were not an object. Additionally, you probably won't do as much system testing as you might do if you had the time and personnel. You can easily see how the time/ budget/quality equilibrium becomes obvious when you consider the above situation.
The project's scope and the list of tasks that you have to perform will be the two most important documents you'll use to pick team members. The schedule arises as a result of the delineation of the tasks and their subsequent durations. Project requirements enumerate what you're going to do, but don't talk about how you're going to do it.
Team members are responsible for estimating the tasks or activities that they'll directly be responsible for. On larger projects, perhaps a team lead might take duration inputs from each of his team members' tasks so that he has an input for a phase duration. But in either case, the SME has a better idea of how long a task will take than the project manager and should be the one doing the estimating. It is up to the PM to add on variables that allow for things such as supervisory and quality overhead, among others.
These are always tough situations to arbitrate. Your primary goal is to bring the two together to try to air the differences in a way that's constructive. Don't meet with them in your office; instead, choose a place that's neutral to all of you. Point out that you notice some friction going on and that you're wondering what the elements of that friction might be, because it's having an effect, or will have shortly, on the outcome of the project. Stress how valuable each of them is to the efforts of the project. Ask questions that don't give either other person an opportunity to blame the other. Try to find creative solutions to the problems.
If this fails, the next step might be to consider asking HR to take a more active role, either through a team-building exercise (which could only occur on larger longer projects where team members work full- time on the project) or in individual counseling.
The developer should not be a part of the conversation. He
has his own work to do and is her peer, not her supervisor. Point out that you©ve researched some security methodologies and illustrate where you find her work to be different than the standards you©ve discovered. Ask her why and try to get her rationale behind the decision. If you find the rationale to be wanting, then tell her you need for her to begin to work toward the standards you©re talking about. Otherwise, let it go. Speak with the developer to tell him that you've investigated the situation and dealt with it. Ask him to try to work more harmoniously with the security specialist. Be sure you tell both what an important part they play in the project.
Large projects will be filled with a plethora of tasks. Some tasks have interrelationships, and the PERT chart can illustrate those interrelationships where the Gantt chart cannot. If you have a handful of highly important tasks, the successful outcome of which is important to other tasks far down the road in the project, then a PERT chart will help you track the interrelationships of the tasks and allow you to monitor successes. Most projects will typically utilize a Gantt chart.
A Gantt chart, by virtue of the fact that it consists of blocks of tasks that may or may not have dependencies (predecessors and successors), is unable to show intricate interrelationships between tasks that are far apart from one another in a large project; PERT charts can do that. Gantt charts don't show the task name (though in Microsoft Project, the task name shows up in the left column); PERT charts do. The chief reason you'd use a PERT chart over a Gantt has to do with the size of the project and the need to monitor intricate interrelationships between key tasks that hinge on the successful outcome of tasks way on down the line in the project.
By virtue of a Gantt chart's limited ability to show dependencies, you in effect have a "poor man's" critical path, though the PERT chart lends itself much more easily to critical-path work.
Was this article helpful?