What Every Successful Project Manager should know!

How to capture, define and communicate successful outcomes in projects.

by Kai Gilb
(who we are)

Companies like Intel, Boeing, Bosch, Credit Suisse, Philips, Qualcomm, Schlumberger, Nokia, Citigroup, HP and many more report achieving excellent results from these specific techniques as taught to them by Gilb.

As of March 2016, well over 20,000 engineers at Intel have been trained in these specific methods as invented and taught by Gilb.

Many smaller firms, like Confirmit, report fantastic numeric results, year after year. Confirmit, in one quarter, increased their product’s Intuitiveness by 175%, Time for users to do a task by 83%, Performance by 1400%.

Here are a few of the ways Gilb uses the outcome-focused requirement method. As part of helping our clients succeed dramatically. Some of them may be useful to you.

1. Identify your critical stakeholders.
It is crucial to have a full view of all the stakeholders that can influence your project's success or failure. Many companies stop at the ‘user' and the ‘owner’ or ‘customer,' you need a list of 20 to 40 stakeholder types to ensure success.

2. Engage these Stakeholders
early and continuously in the contract, requirement specification, development, delivery, and operations. Your success depends on them. Failing to satisfy one critical stakeholder might jeopardize your project. You should, as far as possible involve them in every relevant phase. This early continuously engagement is vital to succeed or avoid failure.

3. Capture what your stakeholders want to be improved.
It is not what they initially will tell you they want. If you deliver exactly what they ask for, the chances are that your project will fail. They will ask for a password, while what they really need is Security, They will ask for specific graphical user interface solutions, what they really need is usability.

Gilb uses time-tested methods to find and specify what the stakeholders really want. When that is clear, the road to success in the project becomes clear.

4. When a customer asks for something,
anything, ask them why, five times, to get to the real need. Sakichi Toyoda, one of the fathers of the Japanese industrial revolution, developed the technique in the 1930s. He was an industrialist, inventor, and founder of Toyota Industries. His technique became popular in the 1970s and Toyota still uses it to solve problems today. We have refined the technique, and our clients use it rigorously, to get to their customers' real needs. When those needs are satisfied, real project success can be claimed.

5. There are four different categories of needs,
that require completely different processing to ensure success. You should know what they are. They are Improvements, Functions, Solutions, and Resources. To avoid confusion and sub-optimization we identify and separate them so we can handle them, and deliver them appropriately. This leads to clarity of thought and sets you up to succeed.

6. We make sure we do not specify the solutions in the functions.
Functions describe what the system must do. Solutions how. To understand what the system must do, our clients keep the functions pure. To open up for a multitude of solutions, our clients keep the functions pure. To be able to prioritize, our clients keep the functions pure. To be able to deliver a solution to great profit for themselves, while their customers are happy to pay, our clients keep the functions pure. Pure as in void of solutions. Pure to what the system does.

7. The real reason any customer wants your product or service
should be understood clearly. We have found that it is never a technical solution they want. Never a function in itself. It is always some improvement for themselves or some other stakeholder. This is a golden opportunity used by our clients as their competitors don’t do this well at all. Our clients identify the improvement, deliver the improvement, and their customers love to pay them. They improve their customer's lives or business in meaningful ways. Their customers become long-term happy paying customers.

What do you think?
Does a customer want, software (that they have to operate and maintain, etc.)? Or do they want specific improvement to their business operations (that the software potentially can give them)? That anyone wants your product, as such, is an illusion. Learn how to focus on the improvements. Gilb has found that clarity on this, leads to success in projects!

8. The needed improvement varies,
there is more or less of it, so to understand and control all aspects of the improvements, we have found that we should quantify the improvements. Gilb has mastered the skill and teachable discipline of quantifying any improvement. Our clients report that it is easy enough, once learned. It gives an unrivaled competitive advantage to quantify and thus clarify. Where others talk vaguely about increased usability, portability, competitiveness, productivity, maintainability, our clients quantify all aspects of these improvements. They can quantify, the current state of, for instance, usability, and the future level needed.

This is huge, and a central piece of advice we have for all our clients.
Quantify all critical improvements that your customers want to achieve.
Then they deliver that improvement to their customer. The improvement is what their customer is paying them to deliver. When they do, they become their customer’s partners.

9. All customers have different needs.
Deliver to their actual needs, not some generic need. We find it critical to have the skill to identify, specify, and deliver the specific needs of the customer. The needs of a banker are specific to the trade. The needs of a mobile phone network operator are specific to that trade. Aquire the skill set to both identify, specify and deliver the general needs as well as the specific to trade needs.

10. The improvement should be free from solutions.
The improvements should define 'which functions' need specific types of improvement and by how much. This requirements statement is made without stating the solution needed to get there.

11. Gilb has found that you can not understand
how much something will cost to develop, nor the value of it based on the list of functions. Functions carry no cost to develop as they 'already exist.' Bankers have been banking for generations. The function, they do, is banking. A website is selling a product. The function is selling; people have been selling for generations. And so it goes for all functions. Your job is not to add functions, but to improve their performance, qualities, and economics. Improve how well they work.

12. Gilb has found that you can not estimate the cost
of developing a competitive product. That is a product that is not a run of the mill product.
There is a two punch secret trick to costing. The trick is understanding what it is worth to the customer and then learning how to do design to cost. Delivering within any resource budget. This we do.

Seven Steps to Success
Simplicity:
1. Plan for, and focus all development activities, on delivering real stakeholder improvements.

Communication
2. For every weekly delivery cycle, estimate & communicate expected development costs and results, quantitatively.

Feedback
3. Deploy to stakeholders, in their environment, real improvements, every week.

4. Measure all critical aspects of the deployment.
5. Analyze deviation from estimates.
Act!
6. Change plans and actions to reflect weekly learning.
7. Circle to point 1.

13. It is the level of improvement
that is needed that determines both cost of development and the value to customers.
The higher the level the more difficult it will be to deliver it. Anybody can build a bad product cheaply, like a bad website. But to make the usability higher and higher, costs more and more. If you want to deliver higher usability than Apple, be prepared to spend billions. If you want to improve the reliability of the space shuttle, be prepared to spend billions. Improving the state of the art costs enormous effort and resources. You should know where you are, where others are, where you need to be. You should know it quantitatively.

14. Not even Tesla is Porsche.
We are not all Porsche, find the levels where you are profitable.
The Porsche 918 Spider does 0-100 km/h in 2.2 seconds. Price about $900k.
The Tesla S P90D with Ludicrous Mode does 0-100 km/h in 2.6 sec. Price about $130k.
Nissan Leaf is about $30k does 0-100 km/h in 10.1 sec.
Where are you with your products and services? Which areas need high levels? Which areas need lower levels? Have you quantified it? What do your customers need? What are they willing to pay for?

15. Organize your project methods
so you have full flexibility in the solution space.
If the customer require solutions, you are stuck with those solutions. Even if the solutions are costly to develop and ineffective at delivering the much needed improvements. The trick is not to agree to deliver specific solutions. Instead, agree to deliver the needed improvements. This will free your team up, they can now use their skills and creativity. They can now come up with solutions that deliver the improvements to your customers. The Customers will be delighted. If your team is smart, they can do it cheaply, and make a huge profit. It's a win-win.

An Invitation

Tom & Kai Gilb have helped numerous companies all over the world to transition from; poor, ineffective ways, to highly profitable intelligent ways, of finding, specifying, developing and delivering customer improvements. The body of experience - which can only be hinted at in the space available here is revealed in the workshop Value Requirement.

How can you learn to succeed in projects?
We have created 3 brand new groundbreaking video tutorials on the subject of What Every Successful Project Manager should know! In the first video tutorial, you will learn about: What your customers want, and what they don’t! And it is not what you think! This is different.
At this moment the videos are free.

Click to Watch the Video Tutorials Now!

We also offer Workshops - for those of you who want to become experts at succeeding in projects.