Introduction

Get familiar with Project Management

As you move ahead in your career, you are likely to face more complex and difficult challenges. Some of these may involve the coordination of many different people, the completion of many tasks in a precise sequence, and the expenditure of a great deal of time and money.

You can do this well, or you can do it badly. If you do this well, you'll complete your projects on time, and with minimal wastage of resources. This will build your reputation as a competent, successful manager. If you do this badly, you'll lose this reputation, and your career will most-likely stall. This is why you need to learn how to manage projects well.

Project Management Definition Is the art and science of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives.

 

What is a Project?

A project is a temporary endeavor, having a defined beginning and end (usually constrained by date, but can be by funding or deliverables), undertaken to meet particular goals and objectives, usually to bring about beneficial change or added value. The temporary nature of projects stands in contrast to business as usual (or operations), which are repetitive, permanent or semi-permanent functional work to produce products or services. In practice, the management of these two systems is often found to be quite different, and as such requires the development of distinct technical skills and the adoption of separate management.

The primary challenge of project management is to achieve all of the project goals and objectives while honoring the preconceived project constraints. Typical constraints are scope, time, and budget. The secondary—and more ambitious—challenge is to optimize the allocation and integration of inputs necessary to meet pre-defined objectives.

“Project management is leading people to get non-routine things done. Every project is different, so managing them is a dynamic and challenging job!” - Unknown author

Project Characteristics

• A start and end date: projects have dates that specify when project activities start and when they end.
• Resources: time, money, people and equipment, used by the project. For example, to produce a brochure you will need a team (designers, copywriters, creative directors, etc.), equipment (computers, printers, paper, delivery trucks, etc.) and money to pay the salaries/fees, buy equipment, and so on.
• An outcome: a project has a specific outcome such as new highway, a satellite, a new office building, a new piece of software, and so on.

Types of Software Projects

• New Development: services & products
• Implementation: customization on existing software (service or product)
• Research: proof of concept for new ideas
• Bug Fixing & Modifications: on existing software (service or product)
• Maintenance & Support: on existing software (service or product)

Project Success Criteria

Whatever its size, a project’s success is based on three main criteria as shown by the following triangle:

              

Your project will therefore be deemed successful if it:

• Delivers the outcome with an agreed upon quality.
• Does not overrun its end date.
• Remains within budget (cost of resources).

Note however, that outcome, time and budget are interrelated, and during a project you may need to do trade-offs between them. For example, if you want to get something done more quickly, you may have to pump in more money into your project for additional resources.

Good, fast and cheap. Any project aims to satisfy all three and it is usually frustrating, stressful, uncomfortable and downright painful.

And usually projects succeed only in achieving two of them:

Good + Fast

First, the easy one. The client wants it good and fast. Set expectations up front that it won’t be cheap. Remind them of the old adage, “You get what you pay for.” Most providers/vendors can handle this one, right? Especially if they know they can charge a premium for the work. Sure, it is stressful in the short term, putting in lots of hours and effort, but it is worth it in the long run.

Good + Cheap

What if the client chooses good and cheap? Shy away from that client, right? Maybe not. They’ll need to be warned not to expect a quick turnaround time. If good quality and a low budget are priorities, then the client needs to know up front that they have to be flexible on time. Set realistic expectations for yourself and stick to them. More importantly, provide a development plan for the client so they can see just how long it might take. This will help them understand your process and is much better than “I’ll work on it when I have extra time.” Explore quick and easy ways of providing some value to them in the short term, like setting them up with one of the various free blogging services. Maybe they don’t need a custom designed site right away.

Cheap + Fast

Finally, the least favorite - cheap and fast. The client needs to be warned to not expect it to look good. This is where things usually break down. You have a hard time committing to a project when you know that it is not going to look good and you’ll be rushed doing it. But perhaps if you’ve had a previous relationship with this client and are comfortable working with them, you’d take on a project like this. Again, it is all about setting realistic expectations. Maybe for now, just getting something out there is what is really important. Maybe it is just a splash page with an email collection form or a Facebook page - something with a URL that the client can use. Then improve it later when there’s more money and time.

Providers/vendors have a responsibility to educate clients regarding all these matters. If you set expectations up front honestly, speak from a position of authority and expertise, and choose your clients carefully, your project stress meter will point down and the overall project satisfaction meter will point up.

Why Do Some Projects Fail?

Generally speaking, any given project can be placed into 1 of 3 categories:

1. Successful: Successful projects are described as being completed on time, within budget, and include all of the originally planned features.

2. Challenged: Challenged projects are in fact operational, but are delivered over budget, behind schedule, and with fewer functionality than was originally planned.

3. Failed: Whereas failed projects are those that are cancelled before completion.

While much praise is given to projects that are deemed successful by the above criteria, some projects are doomed from the onset, and furthermore, an effective project manager will cancel (or fail) a project that is NOT showing promise towards successful completion. Money saved is just as good as money earned! Sometimes this is against the company’s strategy and vision or policy.

If you ask people what factors cause problems in projects these are the sort of things they will say:

• Undefined scope/Scope creep
• Unclear objectives/Unclear expectations
• Vague requirements
• Uncontrolled change
• Unclear roles & responsibilities
• Stakeholder conflicts
• Lack of user involvement/Poor user input
• Change in project size, budget & scope
• Lack of leadership from sponsor/Internal politics/Change in key personnel
• Poor architecture
• Inadequate monitoring & reporting
• Skills that do not match the job/ Inadequate skills for project completion
• Inadequate planning/Poor cost & schedule estimation/Failure to plan/Schedule overruns
• Inadequate communication/ Communication breakdowns/Poor communication between business & IT
• Team know it's impossible but management believe it will be done
• Ignoring reality, wishful thinking/Late failure warning signals/Lack of fact-basis analysis

It is surprisingly rare for people to say that IT technology causes project failure or major difficulties. It is usually project management - or a lack of it - that causes the grief.

There was a touching belief a few years ago that if only one could write down every step a project must tread, then project managers could simply follow the process and out the other end would pop a successful project. Huge methodologies were spawned, money was made. But it isn't like that.

If you wanted to become a plumber you'd learn how to use each of the 50 tools in the plumber's toolkit. On your first, simple job you might only use 2 of them, but knowing which 2 and how to use them to best effect is obviously key. On a large plumbing job you might even use half the tools in your toolkit, but you'll never find any job on which you'll need to use every tool in the box.

The same with project managers: it's all about being equipped with tools for managing risks, defining scope, planning and scheduling, resolving conflict, etc. and then using these tools appropriately if and when needed. You cannot manage projects by rote.

“Calm seas never make skillful sailors.” - Unknown author

Why Are Organizations Using Project Management?

Today’s highly competitive business environment forces organizations to make high-quality products at a lower cost and in a shorter duration. Organizations therefore are increasingly using project management because it allows you to plan and organize resources to achieve a specified outcome within a given timeframe. The techniques of project management also help you manage and anticipate risks in a structured manner. Surveys of organizations using project management have shown that project management allows for better utilization of resources, shorter development times, reduced costs, interdepartmental cooperation that builds synergies across the organization, and a better focus on results and quality.

Who is the Project Manager?

A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development. Many other fields in the production, design and service industries also have project managers.

A project manager is the person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which is cost, time, and scope.

A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized. The project manager job is an interesting job. Running a project means that no two days for you are alike. There are new challenges and bridges to cross on daily basis in your trajectory to accomplish the project objectives.

 

Project Management Skills

Project management skills require that you tolerate politics and can manage people. As a project manager, you have to manage your own team and the relationship with other departments who are either stakeholders or suppliers of certain components for your project.

Leadership skill is the art of the project management skills. Project management is all about getting people to do what you want as a project manager. You need to establish who will work with you and who will work against you. Informal chats help a lot in this sense. Your previous experience with colleagues helps, of course.

As you start your project management job, you will notice that these skills are essential:

• Team Building
• Conflict Resolution
• Negotiation
• Lobbying
• Delegation
• Mentoring
• Coaching and Training
• Communication and Presentation skills are key skills of the project management skills required for a successful project manager. As a project manager, you need to convince many department heads of helping you accomplish the project objectives. Your presentation skills with be of at most importance.
• During any project, your Time Management skill as a project manager could be mean your survival. Wasting time on unproductive meetings, or unscheduled lengthy phone calls could add to your stress and cause the project to fail.
• Your "Know How" of the project subject matter is very important. You need not be a very technical person in the subject matter to manage a project. However, you still need and require some background to it. Don’t expect a civil engineer project manager to manage an IT programming project. It simply does not work.

Tip: Be careful, project managers are looked at the people who don’t have a real job. It is a perception that you might have to live with.

The project management skills require that you understand the following in more details:

• Project manager job
• Software development lifecycle
• Initial project planning process
• Project team building
• Project financial planning
• Project implementation plan

 

The Project Manager Job

The project manager job focuses on certain responsibilities and challenges during the execution of the project such as:

• The project itself in terms of meeting its Objectives, Budget and Schedule.
• Your Team: working as one team and keeping everyone informed is a real challenge. Most probably, you will face the misconception that you left someone behind. Don’t worry, inform him or her and make sure that the process never fails you again. Team building exercises don’t have to be outside the office. The project team should always get together formally and informally to bond or as it’s called now a days "Loving".
• Your Employer: You need to maintain the expected benefits of the project to your employer. You need to maintain the ethics, and policies of your organization. The information sharing with management, secrets of the project, and lessons learned are of most importance.

 

Project Manager Challenges

The project manager job brings with it many challenges. It is a fact that project managers are responsible, but they rarely have the authority.

You cannot "force" others to help you accomplish the project. You have no authority over them. You have to convince them to assist you. This is where your Leadership skills kick in.

Most likely, your team members will come from different department and backgrounds. In a short time, you are expected to get them all to sing, i.e. work, together in harmony. Your management skills should help you face this challenge which is a common phenomenon of the project manager role.

An interesting challenge we noticed with the project manager role is that he or she never have a say in the target date. This date is usually set by the customer or management. Proper scheduling and resource planning should help you around this challenge.

Some project managers are able to deal with such types of stress by taking the stress and don’t passing it to their teams, other project managers just transfer the stress to their teams.

“Project Management can be defined as… a way of developing structure in a complex project, where the independent variables of time, cost, resources and human behavior come together.” - Rory Bruke, 1999.

Software Development Lifecycle (SDLC) Models

Outline of software development models

SDLCs are meant to present an outline of software development teams can cling to. These lifecycles can be distinguished by their way of dealing with the different activities in the evolution of the software as well as their way of handling problems that arise during such a development. There are two types of models: those that go through each of the activities sequentially only once and those that go through each of the phases many times. Those that execute the stages in a lifecycle iteratively produce different artifacts (such as prototypes as well as documents) after each iteration. The major benefit is that even if the whole project is cancelled there are pieces left that could be used in further projects or developments.

Be aware that there is no one best practice for every development process. The following is just supposed to list the most common ways of managing software development processes. Depending on the company structure, complexity of the project, customer requirements and team size as well as knowledge in and usage of tools each of these models has advantages and disadvantages.

Frequently, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.

In general, an SDLC methodology follows the following steps:

1. Requirements Analysis: The system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement. This can be done by interviewing users of the system and consulting with support personnel.

2. Design: The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.

3. Construction: The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.

4. Integration & Functional Testing: The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.

5. Acceptance: Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

There are various approaches to managing project activities including agile, interactive, incremental, and phased approaches.

Regardless of the approach employed, careful consideration needs to be given to clarify surrounding project objectives, goals, and importantly, the roles and responsibilities of all participants and stakeholders.

Waterfall Model

This is one of the sequential activity centered models. All of the software development activities are performed in sequence and there is no iteration. All requirements for one activity are completed and reviewed before the next activity starts. The goal is to never turn back once an activity is completed.

This model is quite easy to understand by each of the parties involved in the process.

However, due to its sequential nature, this model is not capable of dealing with iterations and evolutions. It can't deal with changes and problems that arise during one of the activities since it does not consider a second iteration in one stage. Furthermore, tests aren't mapped to the corresponding activity. Once a phase has been considered complete the results are not going to be changed and are used as input for the next phase. Most of the time, this is too rigid.

Once a project is cancelled, no prototypes or solutions are present that could be reused since the whole development process has to be aborted once a problem is found that had to be dealt with in an activity before the problem arose. The whole development process is lost and no money can be made out of single components or modules that were already developed.

The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

Spiral Model

This is one of the activity based iterative models. It deals with iterations and changes in activities. All of the waterfall's activities are extended into a cycle. Each cycle consists of four phases. In the first phase determination of objectives, alternatives and constraints happens. Alternatives are evaluated as well as risks being identified and resolved in the second phase. In the third phase the development and verification of the current cycle happens. The last phase is used to plan the next cycle. For each cycle the distance from the center measures its proximity to the final product and cost whereas its angular coordinates show the overall progress.

An advantage of this model is its ability to connect objectives to product developments. Risks management is also considered as well as iterations of tasks. It actually combines both development and evolutionary approaches. But the most important advantage is that there are prototypes even if the whole project has to be cancelled.

Nevertheless, it's quite hard to apply in real world scenarios. This model demands many activities in each cycle and requires quite some knowledge in risk management to consider all of the necessary circumstances. Changes in between the cycles are possible but not within one cycle.

Agile Model

Most people have heard of this already as it's been relatively new and most controversially discussed. However, it might also be the one closest to real life scenarios.

There are only four activities: coding, testing, designing and communicating. All of these activities are performed by each of the programmers involved in the project. No documentation is produced as the code represents all design decisions and thus all the knowledge. Pair programming is one of the key concepts in AGILE: two programmers sit in front of the screen and share both knowledge and decisions. While one of them is writing code the other one is keeping an eye on design errors or implementation errors. This way small parts of the system are developed, errors are supposed to be small and there is another person at hand who knows how to move on when one gets ill. The customer is always ready to hand, so that if requirements problems or other problems arise there's always someone to ask.

Together with the manager the customer divides the program into sub-projects that can be dealt with in a certain amount of time (normally one week). This way the customer has the possibility to control the development, costs and can change requirements in between each of the phases. By letting the customer write acceptance tests first, the programmers understand what their goal is, what their program is supposed to do. But the programmers write tests, too, to see if smaller components of the system act the way they're supposed to. After each week the programmers and the manager meet in order to discuss the status and the achievements of the developers. In those meetings the other members are only supposed to listen. After those meetings the members could discuss certain things or have a look at the code.

One of the main advantages is that the customer is involved during the whole development process. And by dividing the project into smaller projects the customer is even able to redefine goals in between the phases. The programmers concentrate on programming and deal with what they're supposed to deal with most of the time: the code. Repeated and also regression tests are used to guarantee quality code.

The drawbacks are obvious: as all of the programmers are dealing with the complete code and all of them are responsible for the whole code, it's hard to catch up at large projects. Empirical studies have shown that AGILE only scales up to 10 programmers. Everything above that creates an immense amount of work for each of the developers.

SDLC Models Summary

As mentioned before: there is neither a worst nor best model. And there is also no generally good or bad approach to managing software development. Each model has its own advantages and disadvantages. And each model is meant to deal with (sometimes only slightly) different aspects than the other. Which of these models should be applied to a certain problem depends on the number of persons involved, the complexity of the software to be developed and the goals and even more aspects. The above introduction might already help evaluating the correct choices for each case. Most of the time the model is chosen indirectly by the way the software is supposed to be delivered and developed. If you really have the chance to choose a model for a future project, it might be best to not only think about the software lifecycle at hand but also about the tools, frameworks, and knowledge in need to support this kind of development.

Project Lifecycle

Like organic entities, projects have lifecycles. From a slow beginning they progress to a buildup of size, then peak, begin a decline & finally must be terminated. Also, like other organic entities, they resist termination!

A project starts with the customer’s need to improve, solve or fix a problem he faces in his domain. The idea or the need develops throughout the different project’s phases, known as the project lifecycle, till the project’s delivery.

 

Note: It is assumed that your project has already been selected, and that a Project Charter has been produced. A Project Charter is generally a document that provides a short description of the project and designates the Project Manager. Sometimes a commercial contract also leads to the initiation of project especially in firms specialized in providing professional/consulting services.

Project Initiation

During the initiating process, you will refine the project goals, review the expectations of all stakeholders, and determine assumptions and risks in the project. You will also start project team selection -- if the project team has been imposed, then you need to familiarize yourself with their skill set and understand their roles in the project. At the end of this phase you will produce a Statement of Work (SOW), which is a document that provides a description of the services or products that need to be produced by the project.

Project Planning

During the planning process, you will detail the project in terms of its outcome, team members’ roles and responsibilities, schedules, resources, scope and costs. At the end of this phase, you will produce a project management plan, which is a document that details how your project will be executed, monitored and controlled, and closed. Such a document also contains a refined project scope, and is used as the project baseline.

Project Execution

During the executing process, you apply your project management plan. In other words you direct your team so that it performs the work to produce the deliverables as detailed in the plan. The executing process also involves implementing approved changes and corrective actions.

Project Closure

During the closing process, you formally accept the deliverables and shut down the project or its phases. You will also review the project and its results with your team and other stakeholders of the project. At the end of the project you will produce a formal project closure document, and a project evaluation report.

Monitoring & Controlling

During the monitoring & controlling process, you supervise project activities to ensure that they do not deviate from the initial plan and scope. When this happens, you will use a change control procedure to approve and reject change requests, and update the project plan/scope accordingly. The monitoring & controlling phase also involves getting approval and signoff for project deliverables.

Project Initiation

With a good start & good high level planning one can consider half of the project complete

Your project has been selected, and you have been appointed as the Project Manager. You should now use the Project Charter or commercial contract, to get the wheels spinning in motion. At the minimum your Project Charter should:

• Designate you as the Project Manager with the authority to use resources to bring the project to completion -- this is formally done by the project sponsor/main stakeholders.
• Provide a short description of the result, outcome, product or services to be produced by the project.
• Refer to the commercial contract as the basis for initiating the project (if there is such a formal contract).

After having reviewed the Project Charter, do the following:

• Ask the Project Sponsor and main stakeholders to share with you any emails, letters, memos, project feasibility, meeting minutes, requirements or other documents related to the project.
• If a similar kind of project has already been completed, get your hands on all the documentation that was produced for that particular project. Set up a meeting with the project manager of that project to ask for advice.

SOW (Statement of Work)

The next thing that you want to do is start working on your Statement of Work (SOW), a crucial document that you will constantly update and use as a baseline for your project. Depending on the size and complexity of the project, and your knowledge about the subject matter, you will need to organize meetings with the stakeholders in order to refine the SOW and get it approved. A well-thought out SOW generally contains the following sections:

Executive Summary

Provides a short overview on the purpose of the project, its background, its scope and sometimes a high-level project plan. 

Goals & Objectives

Describes the objectives of the project. The majority of project management literature recommends SMART objectives that are:

• Specific: your objectives must be clear so that if someone reads them, he or she can interpret them without ambiguity.
• Measurable: you should be able to measure whether you are meeting the objectives or not.
• Achievable: do not try to attempt more than you can.
• Realistic: do you have the resources to achieve your objective?
• Time-specific: specify when an objective will be attained (date)

Project goals example:

Goal	Team Role
Satisfied customers	Product Manager
Delivery within project constraints	Program Management
Delivery to product specifications	Development
Release after addressing all issues	Testing
Enhanced user performance	User Education
Smooth deployment and ongoing management	Logistics Management

Scope

Details the scope that you identified in the Executive Summary of the SOW. In this section, describe the work that will be done. Also, if required, explain what will not be done – this is especially useful to avoid confusion. Note that the Scope section is one of the most important sections of the SOW. Therefore, be very specific when writing it.

Deliverables

A list of the deliverables to be produced by the project. Describe each deliverable in an unambiguous manner that is understood by the team member responsible for it.

Examples of deliverables are:

• Project plan
• Requirements document
• Design document
• Source code
• Test plan
• Test cases
• Release notes
• User guides

Assumptions, Risks & Constraints

There might be a number of unknown issues while you are planning your project. For such issues you need to make assumptions, which constitute a risk. Typical project risks are associated with timeframes, and availability of resources (funding, project team members, supplies, etc.). Detail the identified risks in your project and include contingency plans for each risk. There might also be some constraints on the delivery of the project, e.g. time or cost constraints which are also part of the project’s assumptions and might be treated as risks.

Stakeholders

Definition

Any person or organization that is actively involved in a project, or whose interests may be positively or negatively affected by execution or completion of the project.

Stakeholders are an integral part of a project. They are the end-users or clients, the people from whom requirements will be drawn, the people who will influence the design and, ultimately, the people who will reap the benefits of your completed project.

Importance

One of the key elements of project stakeholder management is the use of influence (“the ability to affect the actions, beliefs and attitudes of other people”) to ensure that people give their support to our projects. It is extremely important to involve stakeholders in all phases of your project for two reasons:

• Firstly, experience shows that their involvement in the project significantly increases your chances of success by building in a self-correcting feedback loop
• Secondly, involving them in your project builds confidence in your product and will greatly ease its acceptance in your target audience.

Types

There are different types of stakeholders and each type should be handled differently:

• Executive: Executive stakeholders are the guys who pay the bills (Sponsors). Typically they are managers or directors who are involved with commercial objectives for the project. They should restrict themselves to commercial considerations and be actively discouraged from being involved in technical design, their experience and skills are vastly different to that of 'typical' end-users.
• End-User: These are the guys that are going to use your product. No one knows more about what the product is supposed to do when it hits their desks than they do. No one! Including you! You may think you know better but if you don't listen to them you're kidding yourself.
• Expert: Sometimes you need input from experts in other fields. People like graphic designers, support reps, sales or sometime lawyers and accountants.Project Managers must communicate with all Project Stakeholders to discover and manage their expectations before and during project execution, to avoid an otherwise successful project being perceived as a failure.

A list of all the stakeholders identified so far in the project. You may also want to detail roles of each stakeholder in this section. You should also make sure to clarify who will be responsible for the signoff of the different deliverables of the project.

Tip: Get your SOW approved by the stakeholders. Once this is done, you will be ready to start planning.

Project Planning

Plans are nothing; planning is everything

You have now gained more knowledge about your project. Working on the SOW helped you refine a number of aspects of your project. You should now start project planning, which involves:

• Detailing the project’s requirements.
• Detailing the activities that make up your project – you will use the Work Breakdown Structure (WBS) to accomplish this.
• Creating a network diagram to determine the dependencies among the activities.
• Identifying the resources (people, equipment, facilities, etc.) you need for the project.
• Establishing a schedule for your project and refining its scope.
• Putting all of the information into a project management plan that will become the baseline document for your project.

Tip: Remember to get the plan approved by the main stakeholders of the project.

“Projects happen in two ways: a) Planned and then executed or b) Executed, stopped, planned and then executed ” - Unknown author

Requirements

Before working in your project, you should determine and analyze your customer’s requirements to be able to define and estimate the needed effort and resources to execute the project. And accordingly to correctly plan for the project’s deadline. Clear and concise requirements help a lot in this exercise. The next steps forward depend a lot on the requirements. They start with the WBS (Work Breakdown Structure).

WBS

To begin the project planning process, start working on the WBS, which is an effective tool that helps you list all the tasks involved in your project. The WBS allows you to group all the tasks under main activities ensuring that you have a clear overview of what you need to execute during the project.

Tip: Careful with the level of detail in your WBS, 3 levels is good; 5 the limit, and 7 becomes unwieldy.

A good way of developing your project’s WBS is by using the major milestones/deliverables that you identified in your SOW. Once the milestones have been identified, brainstorm with your project team to detail the tasks that you must accomplish in order to achieve the milestones. It is advisable to break-up the work into manageable “chunks” (maximum work activity duration of 5-10 man-days, or 40-80 man-hours).
If you and your team are familiar with the project, a milestone approach will work very well. If this is not the case, then consider including in your workshops someone who may not be on your project team but has previously completed a similar project.

“Running a project without a WBS is like going to a strange land without a roadmap” - J. Phillips

Here is a simplified WBS for the design of a website:

For more complex projects with a higher level of detail, you can choose the following format for your WBS:

Project Estimation

The three pillars for the success of any project are cost, effort and quality. The foundation of these pillars is based on estimation technique used for the project. However, historically it has been observed that lots of projects experience cost, effort and schedule overrun or poor quality. In most of cases, the project end up taking alternate paths to fulfill the budget constraint and ends up delivering an inadequate product/application/service.

Tip: A project’s estimate is an estimate; it is never the real value of the project. Though a good estimate should approach the actual value of the project after completion.

Before proceeding in the planning activities, you should estimate your project’s activities and tasks. Based on the WBS you created, you should start estimating the effort each task/activity will take regardless of the resources needed for the task. The project estimation exercise depends on the following factors:

• Project requirements
• Usage of correct estimation techniques
• Historical data for similar tasks/projects
• Experience of the people working on the estimation exercise

These factors control the accuracy of the estimate, so always try to have them on place.

Effort Estimation

Effort estimation is the process of predicting the most realistic use of effort required to develop or maintain software based on incomplete, uncertain and/or noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.

Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. However, the measurement of estimation error is not unproblematic. The strong over-confidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or “almost sure” to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.

Effort Estimation Approaches

There are many ways of categorizing estimation approaches. The top level categories are the following:

• Expert estimation: The quantification step, the step where the estimate is produced based on judgmental processes.
• Formal estimation model: The quantification step is based on mechanical processes, e.g. the use of a formula derived from historical data.
• Combination-based estimation: The quantification step is based on a judgmental or mechanical combination of estimates from different sources.

Below are examples of estimation approaches within each category:

Estimation Approach	Category	Examples of support of implementation of estimation approach
Analogy-based estimation	Formal estimation model	ANGEL
WBS-based (bottom up) estimation	Expert estimation	MS Project, company specific activity templates
Parametric models	Formal estimation model	COCOMO[1], SLIM[2], SEER-SEM
Size-based estimation models	Formal estimation model	Function Point Analysis, Use Case Analysis, Story points-based estimation in Agile software development
Group estimation	Expert estimation	Planning poker, Wideband Delphi
Mechanical combination	Combination-based estimation	Average of an analogy-based and a Work breakdown structure-based effort estimate
Judgmental combination	Combination-based estimation	Expert judgment based on estimates from a parametric model and group estimation

---

[1] Constructive Cost Model - Boehm - 1981

[2] Software Lifecycle Management - Putnam - 1979

Selection of Estimation Approach

The evidence on differences in estimation accuracy of different estimation approaches and models suggest that there is no “best approach” and that the relative accuracy of one approach or model in comparison to another depends strongly on the context. This implies that different organizations benefit from different estimation approaches. Findings that may support the selection of estimation approach based on the expected accuracy of an approach include:

• Expert estimation is on average at least as accurate as model-based effort estimation. In particular, situations with unstable relationships and information of high importance not included in the model may suggest use of expert estimation. This assumes, of course, that experts with relevant experience are available.
• Formal estimation models not tailored to a particular organization’s own context, may be very inaccurate. Use of own historical data is consequently crucial if one cannot be sure that the estimation model’s core relationships (e.g., formula parameters) are based on similar project contexts.
• Formal estimation models may be particularly useful in situations where the model is tailored to the organization’s context (either through use of own historical data or that the model is derived from similar projects and contexts), and/or it is likely that the experts’ estimates will be subject to a strong degree of wishful thinking.The most robust finding, in many forecasting domains, is that combination of estimates from independent sources, preferable applying different approaches, will on average improve the estimation accuracy.

In addition, other factors such as ease of understanding and communicating the results of an approach, ease of use of an approach, cost of introduction of an approach should be considered in a selection process.

WBS-Based Technique

The estimate, depending on the nature of the project, should consider/include the following for each item in the WBS:

• Requirements Activities
  • Requirements gathering
  • Requirements analysis & use cases
  • Requirements documentation
  • Requirements review
  • Prototype
  • Requirements review with customer
  • Requirements signoff
• Design Activities
  • System design
  • UI design
  • Database design
  • Design documentation
  • Design review
• Development Activities
  • UI development
  • System development
  • Integration
  • Unit testing
• Testing Activities
  • Test cases
  • Functional testing
  • Integration testing
  • Security testing
  • Performance & stress testing
• Rework Activities
  • Bug fixing
  • Re-testing
  • Regression test
• User guides & help documentation
• Packaging & Deployment
• Demos
• Estimation
• Planning
• UAT (User Acceptance Test)
• Users training preparation
• Users Training
• Re-estimation
• Re-planning
• Travelling/Transportation
• Ramp up/Training
• Environment setup
• Hidden efforts for
  • Communication
  • Resource allocation
  • Team management
  • Project tracking
  • Project management
• Risks
  • Determined risks
  • Undetermined risks/Contingency

Tip: It is useful to conduct the estimation with the project team to have each members input and to consider all opinions.

Estimating Task Time

There are several ways to estimate the effort of a task, one of which is a formula that combines the optimistic time, the pessimistic time, and the most like time into a weighted average. The formula is:

The PM or project scheduler estimates the optimistic, most likely, and pessimistic durations and plugs them into the formula. For example, optimistic duration = 10 days, most likely duration = 12 days, and pessimistic duration = 17 days.

Expected Time = (10 + (4*12) + 17)/6 = 12.5 days

The formula (in this example, 12.5 days) becomes the starting point for further adjustment such as adding more time for contingency purposes or reducing time due to acquiring additional resources.

How else can a PM deliver tasks or projects on schedule? By decomposing tasks into small work packages that can have their progress measured by the day, week, or month. Being alerted that task delays have occurred within a day or two of when they are supposed to be completed (which is possible when tasks durations are short) greatly assists the PM in developing corrective action plans required for task schedule recovery.

Yes, project estimates are sometimes guesses. Being able to make an educated, consistent estimate using one of these methods, combined with your common sense, will set you apart from your peers.

Size-Based Technique

This estimation technique involves selecting one or two completed projects that most closely match the characteristics of your planned project. The chosen project(s), or analogues, are then used as the base for your new estimate by comparing the size of the feature to one another and to the other completed project. The size is then transformed to effort based on certain equations defined per company standards. A feature may have for example a small, medium or large size, and a comparative methodology is used to determine the size of each feature, then the sizes are summed up and then converted to effort. The sizing estimation is a high level and easy way to determine the project’s estimate and can be very helpful in the very early stages of the project, though the detailed estimation process is still needed.

Psychological Issues Related to Effort Estimation

There are many psychological factors potentially explaining the strong tendency towards over-optimistic effort estimates that need to be dealt with to increase accuracy of effort estimates. These factors are essential even when using formal estimation models, because much of the input to these models is judgment-based. Factors that have been demonstrated to be important are: Wishful thinking[3], anchoring[4], planning fallacy[5] and cognitive dissonance[6].

• It's easy to estimate what you know
• It's hard to estimate what you know you don't know
• It's very hard to estimate things that you don't know you don't know

---

[3] Wishful thinking is the formation of beliefs and making decisions according to what might be pleasing to imagine instead of by appealing to evidence, rationality or reality.

[4] Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily, or "anchor," on one trait or piece of information when making decisions.

[5] Planning fallacy is the tendency to underestimate task-completion times.

[6] Cognitive dissonance is an uncomfortable feeling caused by holding conflicting ideas simultaneously.

Difference between Effort & Duration

Many times our clients ask us “How much time do you need to complete this task?”

Typically the development teams respond by saying “It will take 12 hours to complete it” or “It will be completed in 12 hours”.

The above two sentences have two completely different meanings.

“It will take 12 hours to complete it” refers to an effort of 12 hours required to complete the work.

“It will be completed in 12 hours” refers to the duration within which the task will be completed.

Having said that, lets understand the difference between the terms “Effort” and “Duration”.

Effort refers to the number of person days or person hours required to complete a task. e.g. 12 hours of effort: This means if one person worked on this task nonstop, they can complete the task in 12 hours.

Duration refers to the time period required to complete the task. e.g. 12 hours duration: This means the task will be completed in 12 hours’ time. i.e. This statement does not say how many people will be working on it. It could be 3 people working for 8 hours of effort each and getting it ready within 12 hours duration. It could also be that one person will be working on it for 3 hours of effort, but will have time to complete it only in 12 hours’ time.

In order to get out of this confusion, we have set certain guidelines to be used by our teams whenever interacting with clients on topics of effort and duration.

While giving a proposal/estimate, we always give two numbers:

• Estimated Effort
• Estimated Duration

Also when replying to any client queries on when a task will be ready, we give them two data points: one about effort and the other about duration.

Tip: Estimates should always be performed based on the effort. Plans should always be performed based on the duration.

Cost Estimation

The cost of the project is often fixed before the design is done, and sometimes even before design has begun. Estimation now becomes more of guesswork based upon experience that was gained by screwing up earlier estimates. Without the design, it was quite impossible to know how many lines of code/functions/components/objects would be required. The estimator should rely on data and documents available before one starts the design, such as the functional and non-functional requirements, workflows, and use-cases. Therefore, requirements gathering and analysis is very critical to the project's estimation (design, development, and testing).

The cost of the project is determined based on the effort estimation, in addition to the needed resources cost, e.g. computers, printers, transportation cost… which are considered as direct cost on the project. Other indirect costs should also be included in the definition of the man/day price, examples of indirect costs are: electricity, non-core functions salaries, water, taxes…

Some organizations define rates for each resource depending on his role and his salary scale, and other organizations just have a fixed price for the man/day. In all cases, there should be a risk factor included in the cost estimation.

Contracting Types

There are many ways to price a contract, the most common being Firm Fixed Price and T&M. Selecting the right contract type for your project shouldn’t be a big deal; each one has its own advantages and disadvantages. The Project Manager should have a firm understanding and working knowledge of the various contract types and how their use may affect project outcomes.

• Firm Fixed Price (FFP): The fee to provide the product or services is quoted and fixed for the duration of the contract. FFP contract shifts the project risks to the Provider, who is responsible for cost, performance and profit or loss. The Buyer pays a fixed fee and does not need to know what the Provider is actually spending on the project.
• Time and Materials (T&M): The fee is quoted as an hourly rate plus the cost of materials, supplies, or travel expenses. The T&M contract is used when the Buyer wants full control over the project. Provider profits are factored into the hourly rate and the Buyer is billed for the hours worked.
• Cost Plus: There are actually several variations of Cost Plus, they include: Cost Plus Incentive Fee (CPIF), Cost Plus Fixed Fee (CPFF), and Cost Plus Percentage of Cost (CPPC). Each of these covers the Provider’s costs and an additional fee that is calculated in various ways in an attempt to limit the Buyers costs. A major distinction between CP and FFP or T&M contracts is that with CP contracts, the Provider costs are disclosed to the Buyer for reimbursement.
• T&M with Not to Exceed (NTE): This is a variation of the FFP contract where the Buyers try to get the best potential price while capping total fee paid to the Provider. NTE contracts are usually an attempt by the Buyer to benefit if the project finishes early, and limit exposure if the project runs long.

Tip: Establish a level of signing authority for the project’s budget. If you have to get multiple approvals for spending money, you will waste a lot of time thus impacting your ability to get your project done on time.

There is always business risk with any contract. The business risk can have a positive or negative impact to contract depending on many factors that affect the outcome of the project. From the Buyer perspective, cash is important and cash flow is to be protected. From the Provider perspective, cost control is important to prevent loss of profits. Selecting the appropriate contract type can limit project costs by shifting cost risks or other constraints to the other party.

The project manager, however, may not always be able to choose the contract type and should try to understand the business needs of the clients or customers. All project managers must learn to manage the risks for their respective parties and to be honest about scope, quality, resources, and scheduling.

Responsible project managers will approach project risks in a logical and methodical manner. The project manager should select an appropriate contract type that protects their interests in the contract and limits their risks. Throughout the project, the project manager should aggressively defend the project scope and prevent scope creep using all available tools. Some of those tools include scope control and change management procedures.

Network Diagrams

The WBS allowed you to identify groups of activities that you need to accomplish in your project. However, the WBS does not show the dependencies or sequence between these activities. A network diagram will allow you to illustrate this. Once your network diagram is ready, only then can you realistically start determining your project’s schedule.

A Network Diagram is a visual representation of a project’s schedule. Well known complements to network diagrams include the PERT[7] and Gantt[8] charts. A network diagram in project management is useful for planning and tracking the project from beginning to finish. It represents a project’s critical path as well as the scope for the project.

A good network diagram will be a clear and concise graphic representation of a project.

There are two types of network diagrams: The Arrow Diagram and the Precedence diagram. The arrow diagram depicts nodes for events and arrows for activities. The precedence diagram depicts activities in the order they occur. If you work in IT you will most likely use the arrow diagram. 

‘A’ and ‘B’ each represents an event node. These event nodes refer to an instant when an activity is started or completed. An event node occurs only when all activities entering the node have been completed. The arrow represents the activity that takes place during the event. For example, if a task in a project were “research competition’s ad campaign,” then the event nodes would designate the start and finish of this activity whereas the arrow would designate the activity itself.

Using the arrow and node method, you can depict project dependencies. In the diagram, you see that Event C depends upon activities from Events A and B to be completed, and Event D depends upon Event C’s activities to be completed.

Dotted lines with arrows represent “dummy arrows.” Rather than depict a dependency between two items, these arrows depict a logical relationship. Dummy arrows have no duration. They do not depict an activity. Instead, they transfer logic from one event node to another.

Once the project is mapped out, you can write a key for the visual representation, listing the duration of events and activities. The network diagram will provide you and your project team with a full visual representation of your project.

---

[7] Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

[8] A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project.

PERT Chart

A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either circles or rectangles) representing events, or milestones in the project linked by labeled vectors (directional lines) representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks. In the diagram, for example, the tasks between nodes 1, 2, 4, 8, and 10 must be completed in sequence. These are called dependent or serial tasks. The tasks between nodes 1 and 2, and nodes 1 and 3 are not dependent on the completion of one to start the other and can be undertaken simultaneously. These tasks are called parallel or concurrent tasks. Tasks that must be completed in sequence but that don't require resources or completion time are considered to have event dependency. These are represented by dotted lines with arrows and are called dummy activities. For example, the dashed arrow linking nodes 6 and 9 indicates that the system must be configured before the user test can take place, but that the resources and time required to prepare for the user test (writing the user guides and user training) are on another path. Numbers on the opposite sides of the vectors indicate the time allotted for the task.

The PERT chart is sometimes preferred over the Gantt Chart, another popular project management charting method, because it clearly illustrates task dependencies. On the other hand, the PERT chart can be much more difficult to interpret, especially on complex projects. Frequently, project managers use both techniques.

Gantt Chart

A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project.

Gantt charts may be simple versions created on graph paper or more complex automated versions created using project management applications such as Microsoft Project or Excel.

A Gantt chart is constructed with a horizontal axis representing the total time span of the project, broken down into increments (for example, days, weeks, or months) and a vertical axis representing the tasks that make up the project (for example, if the project is outfitting your computer with new software, the major tasks involved might be: conduct research, choose software, install software). Horizontal bars of varying lengths represent the sequences, timing, and time span for each task. Using the same example, you would put "conduct research" at the top of the vertical axis and draw a bar on the graph that represents the amount of time you expect to spend on the research, and then enter the other tasks below the first one and representative bars at the points in time when you expect to undertake them. The bar spans may overlap, as, for example, you may conduct research and choose software during the same time span. As the project progresses, secondary bars, arrowheads, or darkened bars may be added to indicate completed tasks, or the portions of tasks that have been completed. A vertical line is used to represent the report date.

Gantt charts give a clear illustration of project status, but one problem with them is that they don't indicate task dependencies - you cannot tell how one task falling behind schedule affects other tasks. The PERT chart, another popular project management charting method, is designed to do this. Automated Gantt charts store more information about tasks, such as the individuals assigned to specific tasks, and notes about the procedures. They also offer the benefit of being easy to change, which is helpful. Charts may be adjusted frequently to reflect the actual status of project tasks as, almost inevitably, they diverge from the original plan.

You have now learned how to flesh out the activities involved in a project, determine the sequence of the activities, and establish a schedule. You are now ready for the next step – determining the resources that you need to accomplish your project activities. Note that once you have determined the resources and their availability, you may need to review your project schedule (Gantt chart).

Critical Path Method (CPM)

Definition

Critical Path is the sequence of activities that must be completed on schedule for the entire project to be completed on schedule. This is the longest duration path through the work plan. The duration of the critical path determines the duration of the entire project. Each task/activity on the critical path is called a critical task. If a critical task is delayed by one day, then entire project will be delayed by one day (unless another critical task can be accelerated by one day).

The critical path may change from time to time as activities are completed ahead of or behind schedule. There may be more than one critical path depending on durations and work flow logic.

A related concept is the critical chain, which adds resource dependencies.

The Critical Path Method (CPM) is one of several related techniques for doing project planning. CPM is for projects that are made up of a number of individual "activities." If some of the activities require other activities to finish before they can start, then the project becomes a complex web of activities.

Critical Path Analysis is an effective and powerful method of assessing:

• What tasks must be carried out
• Where parallel activity can be performed
• The shortest time in which you can complete a project
• Resources needed to execute a project
• The sequence of activities, scheduling and timings involved
• Task priorities
• The most efficient way of shortening time on urgent projects
• How long your complex project will take to complete
• Which activities are "critical," meaning that they have to be done on time or else the whole project will take longer

If you put in information about the cost of each activity, and how much it costs to speed up each activity, CPM can help you figure out:

• whether you should try to speed up the project, and, if so,
• what is the least costly way to speed up the project.

An effective Critical Path Analysis can make the difference between success and failure on complex projects. It can be very useful for assessing the importance of problems faced during the implementation of the plan.

PERT is a variant of Critical Path Analysis that takes a more skeptical view of the time needed to complete each project stage.

Activities

An activity is a specific task. It gets something done. An activity can have these properties:

• names of any other activities that have to be completed before this one can start
• a projected normal time duration

If you want to do a speedup cost analysis, you also have to know these things about each activity:

• a cost to complete
• a shorter time to complete on a crash basis
• the higher cost of completing it on a crash basis

CPM analysis starts after you have figured out all the individual activities in your project.