Project

A project is a temporary pursuit (i.e., it has a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables)) that has a unique end.

For example, landing a man on the moon, producing software, and producing commercial airplanes are all projects. A counter example would be producing a commodity.

Contents

1   Etymology

"Project" is derived from Latin "pro" meaning "foward" and Latin "iectare" meaning "to throw".

2   Study

Project management is the discipline of planning, organizing, and controlling resources to achieve specific goals.

The primary challenge of project management is to achieve all of the project goals and objectives while honoring the preconceived constraints. The primary constraints are scope, time, quality and budget.

Many projects of varying sizes reach undesirable end results, such as structural collapse, cost overruns, and/or litigation reason, those with experience in the field make detailed plans and maintain careful oversight during the project to ensure a positive outcome.

3   Function

Every project creates a unique good.

4   Form

Sometimes have dependencies.

4.2   Constraints

Projects have three constraints: time, cost, and scope.

4.2.1   Time

static/images/progressive_vs_regressive_spending.jpg

Progress may be linear, may require investment and sublinear to begin and then superlinear later, or may be simple at first with the last bits being hard (a sort of 80/20 rule).

4.2.2   Budget

Cost refers to the cost all resources, not just money.

Cost is hard to measure precisely because the cost has ramifications as it is used. Software that often leads to user error can be extremely expensive even if development costs were low.

4.2.3   Scope

Scope has two parts:

  • Product scope
  • Project scope

Product scope describes the intended quality, features, and functions of the product — often in minute detail. Documents that outline this information are sometimes called product specifications.

Project scope, on the other hand, describes the work required to deliver a product or service with the intended product scope. Project scope is usually measured in tasks and phases.

5   Properties

Projects are intentional and planned, not spontaneous.

The temporary nature of projects distinguishes them form operations.

6   Classification

7   Techniques

Just as the more a developer works with a project the better they understand it, the more the client works with it, the better they understand it. The development process helps customers understand their own needs, and this is a major source of requirements changes.

How much change is typical? Studies at IBM and other companies have found that the average project experiences about a 25% change in requirements during development, which accounts for 70-85% of the rework on a typical project.

Once requirements are understood, the team should choose an appropriate process model, depending on the project formality, technical environment, staff capabilities, and project business goals.

7.1   Sequential

Choose a sequential approach when: [4]

  • Requirements are stable.
  • The design is straightforward well understood.
  • The development team is familiar with the applications area.
  • The project contains little risk.
  • Long-term predictability is important
  • The cost of changing requirements, design, and code downstream is likely to be high.

7.2   Iterative

The Moon program is an excellent example of an incremental approach. In 1967, they proposed a series of seven missions, each of which would be a step on the way to a landing: [5]

  1. Unmanned Command/Service Module (CSM) test
  2. Unmanned Lunar Module (LM) test
  3. Manned CSM in low Earth orbit
  4. Manned CSM and LM in low Earth orbit
  5. Manned CSM and LM in an elliptical Earth orbit with an apogee of 4600 mi
  6. Manned CSM and LM in lunar orbit
  7. Manned lunar landing

Choose an iterative approach when: [4]

  • Requirements are not well understood or you expect them to be unstable for other reasons.
  • The design is complex, challenging, or both.
  • The development team is unfamiliar with the applications area.
  • The project contains a lot of risk.
  • Long term predictability is not important.
  • The cost of changing requirements, design, and code downstream is likely to be low.

Software favors iterative approaches in general.

Iterative approaches tend to reduce the impact of inadequate work, but they don't eliminate it.

---

# Methodology

## Who

  1. Don't promote a coder to be a program manager. The skills for being a good program manager (writing clear English, diplomacy, market awareness, user empathy, and good UI design) are very rarely the skills for being a good coder. Sure, some people can do both, but they are rare. Rewarding good coders by promoting them to a different position, one that involves writing English, not C++, is a classic case of the Peter Principle: people tend to be promoted to their level of incompetence.

2. Don't let the marketing people be program managers. No offense, but I think my readers will agree that good marketing people rarely have a good enough grasp of the technology issues to design products.o Basically, program management is a separate career path. All program managers need to be very technical, but they don't have to be good coders.

  1. Don't have coders report to the program manager. This is a subtle mistake.

Project management in Silicon Valley is different than in most companies.

In most companies, managers exist to tell people what to do. In Silicon Valley companies, managers exist to help smart people get their work done, and the position is usually considered a chore.

Programmers should argue with managers. Managers should have to persuade programmers since they ultimately right the code. Good managers earn respect by being right and learning to code.

7.3   The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
    • How many steps does it take to make a shipping build from the latest source snapshot?
    • If it takes any more than one step, it is prone to errors.
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you have fix before writing new code?
    • Based on Microsoft's "zero defects methodology"
      • At any given time, the highest priority is to elimiante bug before writing any new code
      • The longer you wait before fixing a bug, the costlier it is to fix
      • Easier to predict how long it will take to fix
        • You can't guesss since you need to identify the buf first
  6. Do you have an up-to-date schedule?
    • Forces you to decide what features you are going to do and cut the least important ones
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during the interview?
  12. Do you do hallway usability testing?

8   History

Until 1900 civil engineering projects were generally managed by creative architects, engineers, and master builders themselves.

Two forefathers of project management are Henry Gantt, called the father of planning and control techniques,[10] who is famous for his use of the Gantt chart as a project management tool (alternatively Harmonogram first proposed by Karol Adamiecki[11]); and Henri Fayol for his creation of the five management functions that form the foundation of the body of knowledge associated with project and program management.

Both Gantt and Fayol were students of Frederick Winslow Taylor's theories of scientific management. His work is the forerunner to modern project management tools including work breakdown structure (WBS) and resource allocation.

The 1950s marked the beginning of the modern project management era where core engineering fields come together to work as one. Project management became recognized as a distinct discipline arising from the management discipline with engineering model.

In the United States, prior to the 1950s, projects were managed on an ad-hoc basis, using mostly Gantt charts and informal techniques and tools. At that time, two mathematical project-scheduling models were developed. The "Critical Path Method" (CPM) was developed as a joint venture between DuPont Corporation and Remington Rand Corporation for managing plant maintenance projects. And the "Program Evaluation and Review Technique" or PERT, was developed by Booz Allen Hamilton as part of the United States Navy's (in conjunction with the Lockheed Corporation) Polaris missile submarine program;[14] These mathematical techniques quickly spread into many private enterprises.

In 1969, the Project Management Institute (PMI) was formed in the USA.[17] PMI publishes A Guide to the Project Management Body of Knowledge (PMBOK Guide), which describes project management practices that are common to "most projects, most of the time."

9   Further reading

10   References

[1]http://www.joelonsoftware.com/articles/fog0000000034.html
[2]http://www.joelonsoftware.com/items/2009/03/09.html "How to be a program manager"
[3]http://office.microsoft.com/en-us/project-help/a-short-course-in-project-management-HA010235482.aspx "A short course in project management"
[4](1, 2) McConnell 2004. Code Complete 2
[5]`Freemany Pryce 2010`_