Discussions

News: The Five Variables of Project Management

  1. The Five Variables of Project Management (12 messages)

    In "The Five Variables of Project Management," Sam Newman offers five things that affect the success of a project, including scope, time, people, process, and risk management. This is a slightly refined view of the traditional "cost, time, quality" triangle in common use. The triangle here is a common way of expressing a simple euphemism: You can have two of the three attributes, but not all three. In other words, you can have low development time and high quality, but the cost will be very high; you can have low cost and high quality, but the development time will be long; lastly, you can have low cost and low development time, accompanied by low quality (which, based on recent software development trends, isn't seen as being a bad choice, apparently.) Mr. Newman's five variables are also documented in slightly more formal language in the Wikipedia's entry on project management, along with more exhaustive explanations of the entire project management cycle. What affects project quality in your view?
  2. Quality is something that a project CAN conserve--although many do not. The quality of the outputs cannot exceed the quality of the inputs. The level of understanding of what the project is about, what it is for, what it is intended to accomplish, seldom comes anywhere close to what it should be. Whatever level it does reach sets a hard ceiling on what is attainable thereafter. Projects do not fail because they are poorly managed. They fail because they are doomed from the outset by inadequately understood requirements. The craft of project management is orthogonal to this.
  3. You have hit the nail on the head in outlining the prevalent problem. But even that (understanding the scope and purpose of the project, the business drivers, etc) is part of project management. Here is where planning for new membes in the team to get familiar with these aspects of the project should be accommodated for. Coming to inadequately understood requirements, I have come across situations where the client for whom the project is being executed, do not have clarity themselves.
  4. Both parties learn from requirements analysis and preliminary prototyping. As a result, scope changes on the way. So does the requirements. So does the risks. I think this is what quite a lot of failed (either not completed or completed but not used) projects miss or do not/cannot accommodate. A strong contract (and the resulting unalterable budgets on both sides) is the greatest risk for a project.
  5. I believe firmly that Quality produces productivity always About "People" I still believe in the old Brooks law Also, the quality (not quantity) of the people is very important. If you have interest in create a good song, will you look for a lot of musicians, or rather will you look for the best musicians?
  6. Low Cost Relatively speaking![ Go to top ]

    Low quality is not necessarily a function of low cost. Development costs are a function of economics, e.g. where in the world the development takes place, e.g. because you have located your development centre out in a rural area, where its cheaper to live, does that mean your quality should suffer. (Maybe it improves, better quality of life etc). Or it maybe how competively you operate your organization. Low cost = low quality. What a ridiculous statement to make! We are not talking about clothing here.
  7. What ?[ Go to top ]

    Not sure what you mean ? Of course projects fail because they are poorly managed - sometimes. Some times they fail for other reasons. Assuring that requirements are adequately understood is an important part of project management. When a PM comes into a situation where that is not the case (the norm), it becomes his task to change that situation, clarify the risk of going ahead without a change, and/or recommend scrapping the project. Pretty standard stuff, IMO.
  8. We all know its not all always getting the requirements wrong... In most of the projects that i have handled, have overseen or witnessed execution as a neutral third party evaluator, the top reasons for failure are: 1. People: Having less number of people than required/anticipated is a big cause of concern, but having wrong set of people can jeopardize the entire project. Team leads with good tech know how, domain expertise and perseverance is a must. The developers may not always live upto the expectation, but teams leads need to. They are the people who are on the field executing the project on a hourly basis. 2. Quality: Unless the concept of quality code is bred into the individual, its generally difficult to get people to turn around quality code. Its import for universities and seniors in the team in inject quality programing into juniors. Its difficult to adopt/adapt at later stages. 3. Feedback: Feedback should not only be relevant, but most importanly timely. Feedback is worth nothing if its not given when required. 4. Scope: The only thing constant in Software development is CHANGE. We all know that there is nothing called fronzed specs. Changes are always round the corner (we are working in circles), its always important to be open to changes. I guess here's where Agile Methodologies come handy...they teach us to accept changes, changes are healthy, as in the process of accepting change, you may set right what could or was going wrong.
  9. Projects do not fail because they are poorly managed. They fail because they are doomed from the outset by inadequately understood requirements. The craft of project management is orthogonal to this.
    Last I checked defining and understanding requirements was part of a project. So if a project fails due to a poor understanding of the requirements, it failed part way down the track, not at the gate.
  10. In my experience, people who care about quality build quality stuff. People who don't always find a reason (cost, time, "the users don't really need that", "we need to get it out the door" etc.) to release something that is low quality. In many respects I agree that understanding of requirements is crucial because one aspect of quality is delivering what the customer needs in a highly usable form. But teams that care about quality (and I include my frequent role as PM here) can make responsible tradeoffs to balance time, scope and resoures, while still delivering quality in every line of code.
  11. 1. People: A right set of people is the most important element to make large projects (above 10M) successful. 2. Scope: Scope control is the second element to be successful although Agile, XP and RUP methodolies allow us to do things incrementaly and iteratively! To this perspective quality comes into the picture only incremental delivery can cut down cost but not the iterative delivery. My 2 cents!
  12. 1. People: A right set of people is the most important element to make large projects (above 10M) successful.

    2. Scope: Scope control is the second element to be successful although Agile, XP and RUP methodolies allow us to do things incrementaly and iteratively! To this perspective quality comes into the picture only incremental delivery can cut down cost but not the iterative delivery.

    My 2 cents!
    People, people, people are the top 3. Great teams build great software. I talk too much about technology. I've seen great teams build sound solutions with COBOL, and I've seen poor teams fail with just about anything.
  13. The four variables I refer to are time, resources, scope and quality. My article on Understanding Project Schedules covers this topic, including a cool Java applet to visualize the relationship between these variables. Sam's article doesn't seem to talk about quality at all, and from what I've seen of the traditional triangle (time, resources, scope), it doesn't mention quality either. I can understand separating out process as its own variable, but I think quality deserves the spotlight more, and my article talks about why that is. Still, I'm glad to see others discussing the importance of making tradeoffs in project management. Too often it seems the client and project manager want it all, and that's just not how it works.