When we talk about professions, we like to know if someone is good at the profession or if he’s bad. A good professional should probably be successful more than the bad one, or? So what about project managers? What is the definition of a good project manager. He should be successful at managing project, then. But what is successfully managing projects? Does this mean that the management should be successful or that the project should be success? But what does it mean to successfully manage a project and what is a successful project? This post focuses on the latter statement: the successful project. In many definitions, you take requirements, budget and time (and sometimes quality) and look before and after. If you can check as many of these groups as “as planned” then the project is a success. But then there is the sense of success. This should not be understated.
We in Sweden can be proud to be on the top three list of building projects. The problem is that it’s not the best but the worst building projects in the world. Just after the opera house in Sidney, we find the soon to be completed building of the tunnel of Hallandsåsen. So, why has this tunnel made it into a list just two places below the Panama canal?
For you who are not up to date with Swedish politics, it all started with the railroad and the heavy industry in Western Sweden. In order to ship all the heavy goods, they wanted the railroad to go through the hill created in the last ice age, instead of over it. This would not only cut time but also enable heavier train loads. It was a sure thing but also a political necessity. It was important to show that we spend money on trains and not just cars.
The problem is that the hill was not helping out here. When they started to drill, it also started to rain in ground water into the tunnel. Not little, but a lot. And the wells in the surroundings were drenched and the tunnel needed to become more water proofed. Then the cattle on the hills started to become sick and die. The water became contaminated by the material they used to seal the tunnels. Also, it was not as easy to drill as they had expected. It was slower and harder. I don’t think anyone disagrees with me when I say that during this time, everyone saw the project as a failure. So there were haltings of the project, companies were sued and there was also legal proceedings regarding the spoiled water.
The projected was halted and then restarted. In 2015, the tunnel is predicted to be opened, 23 years after they started on the tunnel. I mean, Apple started selling the IPod one year after he launched is idea to his team and here it takes 23 years to dig a tunnel which is 8,6 km long. The tunnel was originally thought to cost 1 BSEK but will probably cost at least 12 BSEK in the end. Cattle died, people had to get new water supplies and of course we had all the scared people when we had the poisoning scandal.
A couple of weeks ago, I saw a TV documentary about this project and it was interesting to listen to how people involved saw the project. The engineer who saw this as the most interesting thing he’d ever done. He loved the technical challenges and probably saw the project as a success since they’d been able to overcome all these technical problems. We had the farmer who’d found his dead cattle one morning, who definitely saw the project as a failure: all that wasted money and of course the sadness over his lost animals. Then there was the project manager, focusing on the target: getting the tunnel DONE. He was a bit disturbed about the failed time plans, missed budgets etc but his work (even if there were probably many project managers along the way) was to be completed. They had not given in. The politician then. He was the most interesting person to listen to, from my perspective anyway. He also saw they project as successful, since it would be completed. But here comes the interesting part; he felt that it had been mandatory to complete the tunnel, even if it meant spending all that money since otherwise the spent money would have been waste. Come again? If you’ve wasted 2 BSEK, this money will still be waste even if you spend 10 BSEK more. But if they would have cut the project, then they would have spent the money but would not have a tunnel. Now we spend 12 BSEK and we get a tunnel. That is of course true, but think of all things you can do for 10 BSEK…
Finally, the reported turned to the potential customers. The heavy industry guy. As we all know, they don’t sit down for 23 years and just wait. They’ve found other ways and he didn’t see any big use of the tunnel.
The funny thing is that different stakeholders in a project can have such different opinions on the successfulness of a project. But who’s opinion matter?
One of the things which drew me to TUI Nordic was the work with Lean, which is an integrated part of many departments of the organization. One of the departments is the technical department, which also received a third place in the latest Swedish Lean Awards.
We therefore found the time to hear some of the insights from the technical department: how can we who works with software development (most specifically web development) learn from another department in the same organization?
It was really interesting to see the similarities in challenges in the processes but also see potential improvements we would never have considered had we discussed with other software developers. Not only is this a completely other industry, but also the age of the business and the tradition is completely different.
One of the many highlights was the second opinion. In many cases, another person should make an inspection of the work done. The basic rule is that this is needed if the change is critical but this also has a scale. If you do something to one engine, then the need for inspection is smaller than if the change is done to both engines. This is thought worthy when it comes to code reviews. But then we have the case when an inspection is wanted but not necessary and the technician is alone. The rule then is for the technician to take an appropriate break. What that is must be evaluated from case to case and the technician must for himself make an educated estimation of what that it. In some cases it can be a coffee break but in some cases many hours may be necessary. Thought worthy.
Do you have another department which works comparable processes? Do find the time to hook up and share knowledge. And who knows? You may also learn to know some really nice colleagues as well?
Take a good look at this guy. What, you didn’t know who he is? Of course: he’s pope Gregory XIII, who created the Gregorian calendar.
Here is some Wikipedia quotes about the calendar:
The Gregorian calendar is the internationally accepted civil calendar. It was introduced by Pope Gregory XIII, after whom the calendar was named, by a decree signed on 24 February 1582, a papal bull known by its opening words Inter gravissimas. The reformed calendar was adopted later that year by a handful of countries, with other countries adopting it over the following centuries. The need for the Gregorian reform stemmed from the fact that the Julian calendar system assumes a length for the mean tropical year of 365 days and 6 hours, when the correct value is 365 days 5 hours 48 minutes and 45 seconds. At the time of its introduction the actual date of the vernal equinox was imperfectly known. At the time of the reform the length of the mean tropical year was also imperfectly known. A 400 – year intercalary cycle was introduced which gives an average length for the calendar year which is 27 seconds too long. In the twentieth century Eastern European governments, on the advice of astronomers, introduced a version with a 900 – year intercalary cycle which gives an average length for the calendar year which is only two seconds too long.
When implementing the calendar, 11 days were removed to get in line with the new calendar.
During Agila Sverige, Albin Rännar from Nordic Investor Services, besides from giving a very interesting speech on the death of the budget, explained some of the problems which evolved from the good pope’s new calendar.
If you just look at the description, it looks like a really good idea to reform the calendar. In other words, fix those bugs in the calendar.
But as Rännar pointed at: what about the short term effects? Let’s say that you had a contract with a contractor and according to this contract, you would deliver on July 14th. And then suddenly, there was no July 14th. What then? And even if the actual date was not removed, you might loose 11 days during which you could complete the delivery.
Another person (sorry, but I don’t remember exactly who it was who told the story) then told us about another problem they had when they fixed bugs. Sometimes there was a bug which users used in their business and by fixing that bug, a business opportunity disappeared with the release and without any warning.
And this brings us back to the definition of a bug. For the poor contractor, the missing 11 days was a bug and for the customer losing his business opportunity removing that loop hole probably feels like a bug.
Sometimes fixing a bug feels like creating one, even if there are no regressions.
Having started my career as a consultant, I’m always a consultant. My users are my customers and that is how they are treated. Like customers. Does not mean that I’m their slave, but they should be treated by respect and my main purpose is to bring business value, through the business people.
But also having worked for a product company, everything I work with is regarded as a product. Our web sites are products which our users consume. In this wonderful presentation, Peter Merholtz describes the importance of Experience of a product.
When you might see your product like this:
You should instead see your product like this:
Take an hour and go one step towards The Whole Product concept:
We need to be consistent! We need to be reliable!
Aren’t that nice?
But then consider Sanjiv Augustine’s wonderful statement from APLN:
(Source Jesse Fewell)
A team can be consistent and reliable and still deliver garbage. If you always deliver garbage, you’re pretty predictable, aren’t you? You can truly rely on them delivering garbage. Business as usual.
I have a childhood friend who works with a supplier who he really can count on. He can count on the system failing after each upgrade. He can rely on the support functionality not being able to fix his problems after the delivery and he can be sure to have a lot of angry users on his back. After each upgrade.
What bugs my friend the most is not the individual problems. It’s that no one seems to care that his company loses money every time they upgrade the system. He’s annoyed by that nothing gets better. He feels like the supplier sees the problems as normal. Well, they are since they are consistent, he laughs with panic in his voice when we talk after an upgrade.
I’ve told my friend that he should abandon the supplier, for his company’s sake but mostly for his own health’s sake. And this my recommendation: if you work with a supplier who sees garbage deliveries as the normal state, get out. And if the supplier thinks there are different problems each time and blames this and that, well that is no excuse. If the process consistently produces garbage, it does not matter if the garbage is of type A one day and B the other. It is obvious that the process allows the garbage.
If you instead work at that supplier, you should do something about it. The competition is hard out there and blaming this and that does not help. Look back at your latest deliveries and figure out how many critical errors your company has introduced to your users lately. And no, don’t blame the integrators or the installation guys or even the users. Look at the end product.
Are you proud or are you lining up arguments why you were not to blamed for these incidents?
Jesse Fewell have on his blog presented how Sanjiv Augustine has described his idea of an Agile PMO and how such a solution can fuel continuous improvement.
This is just one take on the problem and it’s handling. Because this is not a problem what can be solved, it’s something you need to work on all the time and on all levels. So what if you have 90% code coverage, work test driven, use scrum and have continuous integration? These are great tools among other tools but if you still work in the garbage spreading business what’s the use of you mixing the garbage with some fine wines?
When I this week was trying to understand, analyze and then present a problem, I realized that many assume that all complexity is created equally, in other words it’s like just adding a new field to a table:
But in the case of my problem, the wanted new complexity added a new dimension to the system:
The increase of possible scenarios would rise exponential would we include the required functionality. The stakeholders hadn’t realized this, since they just saw the requirement as just another field in a table. This became clear to the stakeholders when I described the current scenarios and how many there would be after the inclusion of the requested added complexity.
I could also use the 3D model to visualize how this would work and then the stakeholders could evaluate if it simply was worth it.
I’ve realized just how important It is to clarify for stakeholder if added complexity means a completely new dimension or just added complexity in the current dimensions and how I better can visualize this to stakeholders. Without a picture and hard facts this becomes too vague for many to grasp.
These days, which some even call post agile in software development, McKinsey Quarterly publishes a report by Don Sull: Competing through organizational agility (you need to register to be able to read the complete report.
I believe it’s an interesting article. Now as agile almost is a common boardroom term, I think we must clarify what we mean with agile. Also, it points to the whole organization. It is not enough just to have the software developers embracing agile values if business is as usual for the rest of the crew.
Sull points to studies showing that between 1970 and 1990, firm level volatility has at least doubled and firms that lacks agility perish or are at least not as successful as agile companies.
Sull has also identified three distinct types of agility and what is interesting is that his study shows that many companies relies on only one type of agility; they feel agile since they’ve embraced one of the forms. I will here only list the types and point to the article for examples and more details.
Strategic agility is the possibility to act on those rare chances to create significant value. This require a combination of patience and boldness. This is not to be mistaken for recklessness. Successful strategic agilists systematically minimize the downside risks. Sull also stresses the perseverance; one key is staying in the game until the big chance emerges. This often require cash, size and a powerful patron.
Portfolio agility is the ability to shift resources from less promising to more promising. Many managers in organizations that lack portfolio agility, according to Sull’s study, rarely recommend ending projects that might damage their reputation or risk their and their subordinates work. Uniform set of objectives (for example fixed gross-margin percentage) can also decrease portfolio agility. As a contrast, embracing new blood in the management increases portfolio agility since new managers are not as likely to protect established businesses they themselves has built. Sull’s study shows that many companies rely on disciplined processes for evaluating individual business units lead to portfolio agility, but this is incorrect. This might lead to the data being available, but the decisions might be hard to take anyway. When emotions and politics rather than logic and data controls these decisions, portfolio agility can be maintained. Its is especially important for managers to kill their own darlings, should they prove non promising. Portfolio agile companies uses crisis and changes to renew processes.
Operational agility is when an organization can exploit revenue-enchancing and cost-cutting opportunities in its core business in a fast, effective and constant way. According to Sull, there are many ways to increase operational agility, but he points to two: having systems to spot these occasions and having processes to translate priorities into focused actions.
I’ve just completed the first two days of work for 2010. This is a hectic period for my company. Traditionally, January is a month for summer vacation planning, and this year we’re exceeding the previous year’s booking by a wide margin: last week we had 40% more bookings than the previous year. Great news and a real test of our web sites.
But it’s also a time to think about other challenges. On the personal side, my son is going to preschool this autumn. Myself, I’m planning to complete the short version of La Marmotte, a amateur cycling race in France. 76 km, 2500 m gradient will give me something to work to complete.
Work wise, I know I will be working with 7 habits, empathic leadership and our ongoing struggle to improve our business using our processes and software solutions. I will probably experiment more with kanban and behavioral economics. Finally, my line of business is of course struggling with the challenges of sustainability and the climate question.
Do I need something else? Probably not. I guess I have stuff to do.
When we now move into 2010, I get to summarize my first year at TUI Nordic. It’s been a wildly interesting year and to be frank; I had no idea that I would change so my views, ideas and focus in such a relatively short period. To keep it short, I’ve come to believe that the main focus for product owners, project managers and such should not be in the techniques and methods of software development.
Yes, the product owner should be deeply involved in scrum or kanban and work daily with the team. The product owner should be as fluent as the best of the team members in the chosen methodology, but the methodology is not what brings the ultimate success. What brings ultimate success is understanding what brings business value, find ways to prioritize and to make developers, stakeholders, sponsors and customers understand why we prioritize in a certain way and how things will work. When I say that this should be the product owner’s main focus, I say that this is where his heart should be.
What brings business value?
In so many positions, I have after a while revaluated what the business is. Too many times, the by the management canalized description of the business has not been the truth. Not that they lied, it was more like they didn’t understand this fully. Sometimes they don’t understand the complexity, sometimes they are way off the truth, focusing on the wrong stuff and things don’t bring business value. But the truth is often more complex than first perceived.
When I moved to the leisure travel business at TUI Nordic, I had no idea what the business was. Yes, I knew it is about people, free time and holidays away from home but I had no idea it would be so complex. Just before Christmas I was given a research assignment by my boss and while completing that task, my views were overturned again.
The road to learning what truly brings business value is empathy and social intelligence. Empathic listening to people outside your comfort zone can change your paradigm. Everyone can place a priority number besides a product backlog item but it’s only the empathic listener who can make the best priorities.
How to make propositions a reality
Software development is all about bringing ideas to life in the form of software development. Using a software development methodology is all about techniques to make things becoming built. But developers need to build the right things so that they do the right stuff the right way and everyone else involved need to understand what is built, why and how. Scrum and kanban gives you tools but no tool is better than the person holding it. Again, the leadership and empathic listening is in my view crucial.
It’s not about being the office clown
Don’t understand me wrong. I don’t think that product owners should be dancing about in the halls of the office trying to become the most popular guy on the block. I’ve had such a boss who acted like a speeded rabbit, trying to be cheerful and optimistic. Since he had no depth, it was actually more depressing to see his faked smiles and hollow laughs.
It’s about being like Gene Kranz, here depictured in Apollo 13. You’ve probably seen the movie, but even if you have, sit down and think about the leader in this short sequence. Wouldn’t you like to work for this guy and don’t you think he would make an excellent product owner?
I once worked for an organization, marketing their product as business critical. We spent a lot of energy and effort getting the customers to maximize their use of the system, something which made them dependent on the system too. When it worked, all was of course well and their productivity was amazing.
But the system was not fool proof and sometimes it just stopped working. It didn’t happen all the time but not as seldom that you would not get a bit used to it.
The first time, it was a real disaster. The customers and we consultants panicked. If the system didn’t work, our customers wouldn’t get paid, their customers would not be serviced and since we’d made them so dependent on the system, they didn’t have a really good process to handle this type of situations.
But when it happened again and again and yet again, the same situation wasn’t handled as an urgent issue. Oh, the servers are down. Too bad. We’ll work on it and hopefully the problem is solved soon. Indexed has as so often caught this in a simple image:
Since we let the failures happen too many times, we lost a sense of urgency. We knew the system would fail so we weren’t that serious about it. A real horror story was when a customer was left with a non working system for many days, not being able to bill his customers.
So, what happened to the customers? Well, first of all the trust was broken. We had stated that we would treat his system as business critical, but that was not how it worked. They lost faith in the product and I guess a couple of customers built a separate system for the times when the system failed. The customer staff of course lost all their trust. Many are stressed at work and need their critical systems to work. I guess they did not recommend this system to their friends and families.
Does this mean that systems cannot fail? Well, of course they can and they will but if you are building business critical systems, the likelihood of failure should be low and not functioning systems should be seen and handled as disasters. Of course that does not apply to all functions in a system. There are few really mission critical functions of a system.
When developing systems we must clarify SLA’s and identify these mission critical tasks in the systems. And we need to build a sense of urgency into our crew when disaster strike.