Project Management Concepts

Project Management Concepts



Project Management Concepts

Chapter 31 - Project Management Concepts


  • Project management involves the planning, monitoring, and control of people, process, and events that occur during software development.
  • Everyone manages, but the scope of each person's management activities varies according his or her role in the project.
  • Software needs to be managed because it is a complex undertaking with a long duration time.
  • Managers must focus on the fours P's to be successful (people, product, process, and project).
  • A project plan is a document that defines the four P's in such a way as to ensure a cost effective, high quality software product.
  • The only way to be sure that a project plan worked correctly is by observing that a high quality product was delivered on time and under budget.


Management Spectrum

  • People (recruiting, selection, performance management, training, compensation, career development, organization, work design, team/culture development)
  • Product (product objectives, scope, alternative solutions, constraint tradeoffs)
  • Process (framework activities populated with tasks, milestones, work products, and QA points)
  • Project  (planning, monitoring, controlling)



  • Stakeholders (senior managers, project managers, practitioners, customers, end-users)
  • Team leadership model (motivation, organization, innovation)
  • Characteristics of effective project managers (problem solving, managerial identity, achievement, influence and team building)


Factors Affecting Team Organization

  • Difficulty of problem to be solved
  • Size of resulting program
  • Team lifetime
  • Degree to which problem can be modularized
  • Required quality and reliability of the system to be built
  • Rigidity of the delivery date
  • Degree of communication required for the project


Team Organizational Paradigms

  • Closed paradigm (top level problem solving and internal coordination managed by team leader, good for projects that repeat past efforts)
  • Random paradigm (team loosely structured success depends on initiative of individual team members, paradigm excels when innovation and technical breakthroughs required)
  • Open paradigm (rotating task coordinators and group consensus, good for solving complex problems – not always efficient as other paradigms)
  • Synchronous paradigm (relies on natural problem compartmentalization and team organized to require little active communication with each other)


Toxic Team Environment Characteristics

  • Frenzied work atmosphere where team members waste energy and lose focus on work objectives
  • High frustration and group friction caused by personal, business, or technological problems
  • Fragmented or poorly coordinated procedures or improperly chosen process model blocks accomplishments
  • Unclear role definition that results in lack of accountability or finger pointing
  • Repeated exposure to failure that leads to loss of confidence and lower morale


Agile Teams

  • Teams have significant autonomy to make their own project management and technical decisions
  • Planning kept to minimum and is constrained only by business requirements and organizational standards
  • Team self-organizes as project proceeds to maximum contributes of each individual’s talents
  • May conduct daily (10 – 20 minute) meeting to synchronized and coordinate each day’s work
    • What has been accomplished since the last meeting?
    • What needs to be accomplished by the next meeting?
    • How will each team member contribute to accomplishing what needs to be done?
    • What roadblocks exist that have to be overcome?


Coordination and Communication Issues

  • Formal, impersonal approaches (e.g. documents, milestones,  memos)
  • Formal interpersonal approaches (e.g. review meetings, inspections)
  • Informal interpersonal approaches (e.g. information meetings, problem solving)
  • Electronic communication (e.g. e-mail, bulletin boards, video conferencing)
  • Interpersonal networking (e.g. informal discussion with people other than project team members)


The Product

  • Software scope (context, information objectives, function, and performance)
  • Problem decomposition (partitioning or problem elaboration - focus is on functionality to be delivered and the process used to deliver it)


The Process

  • Process model chosen must be appropriate for the:
  • customers and developers
  • characteristics of the product
  • project development environment
  • Project planning begins with melding the product and the process
  • Each function to be engineered must pass though the set of framework activities defined for a software organization
  • Work tasks may vary but the common process framework (CPF) is invariant (project size does not change the CPF)
  • The detail of the actual work tasks used to complete each framework activity and dependent on the size and complexity of the project
  • The job of the software engineer is to estimate the resources required to move each function though the framework activities to produce each work product
  • Project decomposition begins when the project manager tries to determine how to accomplish each CPF activity


Signs of Potential Project Failure

  • Developers do not understand customer’s needs
  • Product scope poorly defined
  • Changes poorly managed
  • Chosen technology changes
  • Business needs change or ill-defined
  • Deadlines unrealistic
  • Users are resistant
  • Sponsorship lost or never obtained
  • Project team members lack appropriate skills
  • Managers and practitioners avoid best practices and lessons learned


Avoiding Project Failure

  • Start on the right foot
  • Maintain momentum
  • Track progress
  • Make smart decisions
  • Conduct a postmortem analysis


W5HH Principle

  • Why is the system being developed?
  • What will be done by When?
  • Who is responsible for a function?
  • Where are they organizationally located?
  • How will the job be done technically and managerially?
  • How much of each resource is needed?


Critical Practices

  • Formal risk management
  • Empirical cost and schedule estimation
  • Metric-based project management
  • Earned value tracking
  • Defect tracking against quality targets
  • People-aware program management


Source: https://highered.mheducation.com/sites/dl/free/0078022126/1017028/summary31.doc

Web site to visit: https://highered.mheducation.com

Author of the text: indicated on the source document of the above text

If you are the author of the text above and you not agree to share your knowledge for teaching, research, scholarship (for fair use as indicated in the United States copyrigh low) please send us an e-mail and we will remove your text quickly. Fair use is a limitation and exception to the exclusive right granted by copyright law to the author of a creative work. In United States copyright law, fair use is a doctrine that permits limited use of copyrighted material without acquiring permission from the rights holders. Examples of fair use include commentary, search engines, criticism, news reporting, research, teaching, library archiving and scholarship. It provides for the legal, unlicensed citation or incorporation of copyrighted material in another author's work under a four-factor balancing test. (source: http://en.wikipedia.org/wiki/Fair_use)

The information of medicine and health contained in the site are of a general nature and purpose which is purely informative and for this reason may not replace in any case, the council of a doctor or a qualified entity legally to the profession.


Project Management Concepts


The texts are the property of their respective authors and we thank them for giving us the opportunity to share for free to students, teachers and users of the Web their texts will used only for illustrative educational and scientific purposes only.

All the information in our site are given for nonprofit educational purposes


Project Management Concepts



Topics and Home
Term of use, cookies e privacy


Project Management Concepts