I’ve just attended a very interesting webinar on “New Rules for IT Project Value”, which I would like to share with you. Rather than measure projects by the expected “triple constraints” (cost, time, and quality) Standish Group came up with a valuemeasurement system. Value-Based PM is a set of rules that can be used in any environment to create project value.
To achieve a Value-Based PM environment, Standish Group recommends following these 20 rules:
Rule #1 Leaders should lead.
And this does not apply to PM but to a skilled executive sponsor! Each project should have such a sponsor who is responsible for inspiring, promoting collaboration, decisions & consensus!
Rule #2 Speed thrills
A quick user feedback throughout the project is essential!
Rule #3 The Rule of Three
Good things come in threes. Limit your project goals to 3.
Rule#4 Complexity causes confusion and costs
Make it simple. The best way to solve a complex problem is to find a simple solution.
Rule #5 Don’t fail to fail.
That’s my favourite. So many people around me do not take decisions because they are afraid of failure. I say, only people who do not do anything do not fail. You cannot make real progress without risk.
Rule #6 Smaller is better.
Divide your project to smaller chunks/phases, as small projects deliver value and it’s much easier to keep the motivation up when you deliver quickly!
Rule #7 Run emotions high.
Nothing affects project value more than the organisational culture. Understand the level of your company emotional maturity and constantly work to improve it.
Rule #8 Eagles don’t flock.
Engage highly talented people who understand both the business and the technology.
Rule #9 Just do it.
Take decisions in a timely manner. Value-Based PM recommends the organization measure, benchmark, and improve the decision-making process.
Rule #10 The Rule of Ten.
Focus on quality versus quantity. It’s better to deliver 1 quality feature than 2 poorly constructed ones. At each quality level you will pay 10 timesthe cost to find and correct defects.
Rule #11 Always be communicating.
3 ways of improving communication in your project: 1) Have one central place. 2) Allow for personal communication preferences. 3) Make your customer a part of your team! If you are interested in more please read my article (in Polish) in Magazyn Zarządzanie Projektami
(4th edition) or here
Rule #12 People over process.
People over process. Create and maintain community – a unified body of individuals with common interests interacting and collaborating! Collaboration creates value. More on collaboration in my previous post
Rule #13 Only do what is important.
The Standish Group has found that fewer than 20 percent of software features actually get used. The Standish Group also has concluded that most PM processes and tools do not add value but rather add overhead to the project. Scary, isn’t it?
Rule #14 Don’t confuse activity with progress.
Agile methods focus on delivering product and not on useless processes. Agile methods consist of iterations, small groups, fast feedback, and continuous retrospectives. Implementing an agile process or methodology using a small project philosophy goes a long way toward adopting a Value-Based PM environment.
Rule #15 Don’t reinvent the wheel.
Use existing components instead of building it from scratch.
Rule #16 A fifth of a loaf is better than none.
Value-Based PM focuses on the obvious needs. Requirements are always incomplete!
Rule #17 Action is better than clarity.
Project teams should reduce or give up control of the business objectives to encourage and promote innovation. In Value-Based PM the business objectives are dynamic as the project progresses.
Rule #18 Only count what counts.
Select only three measurements and track those measurements.
Rule #19 Lay a good foundation.
Have a standard operating infrastructure and standard development environment!
Rule #20 Tools are or fools.
Sophisticated tools cost and add work to feed them. The investment in these tools takes away from more value efforts such as improving executive sponsorship, emotional maturity, and the decision process. 1