9/11/15

5 Tips for Being an Effective Tech Lead

The time a developer spent focusing on writing well-designed code does not translate into the skills necessary for understanding people, resolving conflict, or suddenly having to juggle more tasks than what they can possibly achieve by themselves.
Here are my five tips for being an effective Tech Lead.

1. Learn to Delegate

As a developer, you get a kick from working out what the hard, technical problem is to solve. You research different ways to solve the problem, seeking the most simple solution and celebrate a victory when you want that red, failing test go green.
As a Tech Lead, you cannot take on all the coding tasks, and cannot take on all the hard or interesting problems regardless of your experience. You have many more responsibilities that need time and attention, and if you are focused solely on a single task, those other responsibilities will fail to be fulfilled. When you take on the harder problems, it also misses an opportunities for other developers to grow and problem solve which will lead to frustration and potentially people leaving your team!
Of course, there are some problems when your experience and knowledge are important but you do not want to be a bottleneck in solving problems, so you want to find a way to delegate but still be involved. Solutions might include kicking off a design session with developers to talk about general approaches, and reviewing progress with the developer on a regular basis to see if things are on track.
As you and the developer build trust with each other, you can be less involved and fully delegate an activity to let you focus on more important tasks.

2. Find Time to Code

The role is called "Tech Lead" for a reason, and it is essential that you find some time to spend in the codebase. Being involved in the code helps you build respect with the rest of the team, but it also helps keep your knowledge up to date and current with constraints, problems and the "shape" of the current codebase.
If you do not spend time with the code, you run the risk of invoking the "Ivory Tower Architect" anti-pattern, leading technical decisions without understanding their real implications for implementation or maintenance. This anti-pattern has numerous side effects including destroying trust with developers, increasing the development time of new features, and increasing the accidental complexity of your software systems.
There are many different ways a Tech Lead can find time to code, but it is essential that you make it a priority. This often means making difficult choices about where you spend your time. Tip #1 should help increase the amount of available time you have. I know some Tech Leads who will block out time in their calendar to ensure that there is always time during the week to write or review code with the other developers. I know of other Tech Leads who review commit logs, and provide feedback to developers - similar to a loose pair-programming style.

3. Visualise Your Architecture

I have worked in several teams where developers had no idea how their task fit into a bigger picture. A small technical decision made by a developer might have a wider architectural impact but impossible to prevent if developers to do understand the broader picture.
An effective Tech Lead often has a visual representation of their system architecture on-hand and uses it to have discussions with developers. There will often be different views of the architecture (logical, deployment, etc) and each diagram helps developers see how their task fits into a broader system architecture.
A whole-team whiteboard session is often a useful exercise for reviewing the overall architecture as it evolves over time to meet differing requirements and the discussion during the session is even more important than the diagram. Focus on key quality attributes that drive your architectural vision (scalability, performance, usability concerns, etc) and how they have shaped your architecture. Call out assumptions and the historical context to help developers guide their everyday decisions.

4. Spend Time 1-on-1 With Team Members

An effective Tech Lead will not be measured in how many coding tasks they complete. They are measured by how effective their software team is. Anything that a Tech Lead can do to make each person on their team better makes the overall team better. Sit down with members on your team to understand their backgrounds, their strengths, their interests and their goals to understand how the people in your team fit together as a group.
Connect developers with opportunities for them to grow. This means allowing them to take risks so they can learn and grow, but also contribute to the team. Encourage people to share knowledge across the team and find ways to help each team member connect with each other.

5. Learn to Speak the Language of the Business

To be an effective Tech Lead, you will need a great relationship with people outside of the development team including people like Product Managers, Marketing, Sales and CxOs. They will not understand the vocabulary you accumulated as a developer, and talking to them in terms of frameworks, technical tools and platforms will only confuse them.
An effective Tech Lead finds ways that non-technical people can understand technical concepts and the best way to do that is to find the terms that business people use and find ways to explain tasks in those terms. Use visual models, whiteboard sessions and metaphors to help business people understand technical concepts and their implications. You might practice on friends or relatives who don’t work in technology to see if you can succinctly explain an idea.
Minimise the translation layer as much as possible by bringing business terms into the development team and encouraging their use as much as possible. The better the developer team uses these domain terms, the better their understanding and empathy with business stakeholders will be.

(Patrick Kua)

8/31/15

36 steps to success as technical lead

The tech lead role can be treacherous at times. While the name implies leadership, most of the times it doesn’t come with implied authority like a manager role for example. It often happens that this role is in a no-man’s-land where it brings a lot of responsibility but not enough formal authority. In order to successfully help a project from this position one has to navigate through narrow and convoluted straits.

The role is not clearly defined in most companies and it is placed in a continuum starting at the senior programmer level and extending to architecture and management positions.

More often than not the tech lead shares the responsibility for a project without being given full formal authority. In this kind of situation success will be based on the ability of the tech lead to combine his “tech” and “lead” talents in a manner that will get results from the team and will get approval and support from the management and the business.

I assume you are new at technical leadership. You are perfect for the job from a technical point of view but you lack experience in leading others while bearing the responsibility for their work. There is no easy answer and no off the shelf solution for success. Here is a list of guidelines that should get you started and help you in your quest.


Set yourself up for success


1. Define early on what success means for you, the team and the business

You have to have a clear idea of what you want. You also have to understand what team members and the management want. You also have to be aware that what people really want, what they say the want and sometimes even what they think they want are very different things. Try to be very honest at least with yourself. Success has different definitions for different people. If there is a big disconnect between these definitions you have a problem before you start.


2. Believe in the project: idea, architecture, time, team

You cannot have any kind of success if you are convinced you lead a team of morons to implement a stupid idea using the wrong architecture in a ridiculously short time. You have to really believe in the project to have a chance to success. This does not mean lie to yourself. It means do whatever you can to understand your concerns and work on them with the management. As for the architecture, it is best if you have a heavy word or if you are the architect.


3. Understand the domain, the business requirements and the technical challenges

You should be an expert in the technologies used for implementation. You also have to become very knowledgeable in the problem domain and the business case. This will help you understand the business decisions dropped on your head from upstairs and also will help you stand a chance at negotiating them.


4. Know your team: strengths, weaknesses, ambitions and personalities

Software is created by people. Your job as a “tech lead” is to support them in doing that, both from a technical point of view and at a human level. You want to lead a team of motivated and enthusiastic people. But each person gets motivated by different things.


5. Have a plan as a result of a planning activity

“Plans are useless but planning is essential” – (Dwight D Eisenhower, US President, general 1890-1969). Planning will make you think about the problems you face in detail. Also keep in mind that “a plan is just a list of things that ain’t gonna happen” – (Benicio Del Torro in “The Way of the Gun”).


6. Be part in the design of everything

This does not mean do the whole design. You want to empower team members. But your job is to understand and influence each significant subsystem in order to maintain architectural integrity.


7. Get your hands dirty and code

Yes you should take parts of the code and implement them. Even the least glamorous parts. This will help you not getting stuck alone between management and the team. It will also help you gain respect in the team.


8. Act as a communication proxy for your team

In long complex projects with big teams communication is one of the most complicated aspects. The more people you have involved in solving a problem the bigger the communication matrix becomes. Since people need information to be able to make the right decisions this will lead to an exponential increase in the time consumed for communication. Agile methodologies alleviate this problem. But in the end it is up to you to propagate important information to the right people.


9. Make sure everybody understands the big picture: their work has implications

This will help you greatly because will allow team members to design and implement in a way that you don’t have to fight. It is also hard work from your part.


10. Fight for architecture and design consistency

Doing the right thing from the design and architecture point of view is not more costly. It is actually cheaper in every project longer than a couple of months. Every early investment in architecture pays for itself later during integration and maintenance. Even if you have to admit an occasional hack or prototype in the code base you should contain it in very specific modules.


11. Know the status of everybody’s work and detect slippage

This allows for corrective actions and for early communication with the management. You don’t want to be caught by surprise. Remember that during 90% of the allocated time for a task the code is 90% complete.


12. Record technical debt if you need shortcuts but try to maintain architectural integrity; report the debt

This one is very important for products that will have multiple releases. Technical debt should be analyzed at the beginning of each iteration.


13. Use the process that makes sense in your particular case

Tough one. Sometimes (most of the times?) the process is not up to you. In the enterprise usually the process is pre-decided. But always keep in mind that the process in itself means nothing. It is the people who give meaning to the process. Good people can make the worst process work while the wrong team cannot make any process work. Waterfall can be implemented in a very agile way and the agile methodologies can be applied with “rigor mortis” agility (see The Agile 800 Pounds Gorilla).


14. Avoid dogmas – question why everything is done the way is done; make sure everybody else knows the reasons

Sometimes I hear from programmers: we are agile and combine XP and Scrum and we also do TDD (Test Driven Development – I still hope for a TDD that means Thought Driven Development). The questions that pop up in my mind are: Do you need all those? Do you “really” do them by the book?

Anyway the point here is don’t do anything just because it is the way it has always been done. Understand why. Then explain the reasons to all team members. Rinse and repeat.


15. Avoid design by committee; listen to everybody but make your own decisions

No good design is born from referendum. There are lots of people making wild exotic suggestions when their a$ is not on the line. There are also excessively prudent ideas born from fear. Even with good ideas you have to filter them and make them yours before you can include them in the design. A good architecture and a good design is usually born in one mind, an open mind that looks around. The obvious example is Linux.


Build your relationship with the team


16. Gain the team’s respect with the quality of your work and by doing what you are preaching

If you want something from a group of people you have to be an example for that something. Show them quality if you want quality. Show them enthusiasm if you want enthusiasm. And so on… but with a team of programmers don’t forget to show them good code and good design.


17. Be fair

Being perceived as fair by your team is essential and unfortunately this is really hard to get because you have to say no sometimes. No, to good ideas that will improve the product. No, to bad ideas that will improve somebody’s resume. The way you say “no” and when you say “no” and to whom you say it makes all the difference.

Also be fair in allocating work. If somebody is more capable and is able to do more, be sure to compensate that person in some form. A programmer whom I respect deeply once said to me: “I finished my work and then I started to help John. He was way behind and the boss asked me to give him a hand. After a week we were still behind because John’s code was a mess and I had to basically start over. And at that time, in a meeting, the boss screamed at me because I didn’t do John’s work faster!”. The story speaks for itself.


18. Admit your mistakes

Goes hand in hand with the previous advice. It takes courage to admit your mistakes and to make yourself vulnerable in front of your team, but this will build trust between you and the team. Just be careful not to make mistakes too often.


19. Publicly recognize both team’s and individual members’ merits

Think about a scenario: an emergency arises and you ask a team member to take care of it. The person solves the crisis, perhaps with a lot of personal effort. Then, in a meeting with the whole team, and higher management, you say “We worked hard as a team and we solved it”. If you don’t mention the person by name they will never forgive you.


20. Don’t blame anybody publicly for anything

In fact as a tech lead you cannot blame anybody but yourself for anything. The moment you blame a team member in public is the moment when the team starts to die. Internal problems have to be solved internally and preferably privately.


21. Build morale and confidence by offering early victories to the team and to its individual members

I cannot over stress the importance of this advice. Victories bring victories and sometimes you have to set up the first one. If you offer the chance to early victories the team will gel faster and the enthusiasm will create other successes. The best scenario is when somebody manages to accomplish something he was sure he cannot do.


22. Match people and tasks based on skills and their personal preference if possible; explain your decisions

Another difficult skill to master. Everybody in the team wants the glamorous parts that use the latest technology. You have to match every task with a person and you have to make them happy with what they got. It has to be challenging and comfortable at the same time for all of them. This is no easy feat but it can be done. You have to go back and look at what motivates each person in your team.


23. Work the estimates with the team don’t come up with them

If you don’t do it you will be perceived as not fair. Also keep in mind the estimate, to have any meaning, has to be done by the person who will do the work.


24. Mentor people

It is your job to raise the education level of your team. By doing this you can build relationships at a more personal level and this will gel the team faster and harder. It is very effective with more junior people in the team but there are ways to approach even more senior members, just try not to behave like a teacher.


25. Listen to and learn from people

Even if you are the most experienced developer on the team you can always find new things and learn form others. Nobody is a specialist in everything and some of your team members can be domain specialists who can teach you a lot.


26. Explain your technical decisions

There are many reasons for this advice. By trying to explain your decision you get to understand it better. You get valuable feedback. You ideas are bought faster. You make people understand that you value their opinion.


Build your relationship with the management and business people


27. Be sure you have authority along with responsibility

Depending on the situation this might be either implied or impossible to get. Usually it’s in between – you are backed up and given some authority but you have to work and get the rest as earned authority by making the team respect you. It is always useful to understand where you start.


28. Be sure you get requirements and not architecture/design masked as requirements

Sometimes business people fancy themselves architects, sometimes they just speak in examples. They can ask for technology XYZ to be used when what they really mean is they want some degree of scalability. Be sure to avoid hurting feelings but be firm and re-word everything that seems like implied architecture. Get real requirements. To be able to do this you have to understand the business.


29. Explain technical decisions in business terms

Don’t explain your technical decisions to your managers the same way you explain them to your team. The business benefit derived from our decisions is all that matters here. Technical benefits, while sometimes understood, may look like over engineering.


30. Try to be accurate in your estimates; avoid being too optimistic and don’t push it with hidden padding; explain the need for padding

Your managers are not born yesterday. They understand software development better than you imagine but they look at it from a different direction. Present your team’s estimate and clearly add the padding as a result of unknowns in the presented estimate.


31. Set reasonable expectations

Don’t be too optimistic. If this is your first project as tech lead be cautious when you predict time to market, quality and feature coverage. It is always better to promise less and deliver more than the other way around. There are always hidden dangers in any quest.


32. Understand the relationships and dependencies with other teams or projects

If the project is part of a bigger one you have to know who depends on you and what they want and who you depend on and tell them what you want.


33. Accurately report the status with alarms, explanations and solutions; report any technical debt

While being punished as the bearer of bad news is a valid concern, a good manager will always appreciate early warnings. Just be sure to bring at least a solution with your problem. The technical debt and its effects have to be communicated when they are significant since they can influence the business.


34. Resist pressure for change in requirements, and more important for shortcuts…

…but don’t forget the requests might have a sound business reason. Be flexible, trade and negotiate if necessary.


35. Be aware of politics

I am not going to get in juicy details here since this was discussed extensively many times. Just be aware politics exist and the fact is natural in any human society.


36. React to surprises with calm and with documented answers

Never get carried away with refuses or promises when confronted with surprises. Ask for time to think and document/justify your answers. It will make you look better and it will get you out of ugly situations.


I got to the end of my long list and I realize it is still too short. But as always experience will be the best teacher. This is just a starting point. Good luck!

8/28/15

Technical Debt

The term technical debt was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term.
Ward didn't develop the metaphor in very much depth. The few other people who have discussed technical debt seem to use the metaphor mainly to communicate the concept to technical staff. I agree that it's a useful metaphor for communicating with technical staff, but I'm more interested in the metaphor's incredibly rich ability to explain a critical technical concept to non-technical project stakeholders.

What is Technical Debt? Two Basic Kinds

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don't identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We'll call this general category of debt Type I.
The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this release done on time, there won't be a next release" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to reconcile these two databases, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship." Or "We have some code written by a contractor that doesn't follow our coding standards; we'll clean that up later." Or "We didn't have time to write all the unit tests for the code we wrote the last 2 months of the project. We'll right those tests after the release." (We'll call this Type II.)
The rest of my comments focus on the kind of technical debt that's incurred for strategic reasons (Type II).

Short-Term vs. Long-Term Debt

With real debt, a company will maintain both short-term and long-term debt. You use short-term debt to cover things like gaps between your receivables (payments from customers) and expenses (payroll). You take on short term debt when you have the money, you just don't have it now. Short-term debt is expected to be paid off frequently. The technical equivalent seems straightforward. Short-term debt is the debt that's taken on tactically and reactively, usually as a late-stage measure to get a specific release out the door. (We'll call this Type II.A.)
Long term debt is the debt a company takes on strategically and proactively--investing in new capital equipment, like a new factory, or a new corporate campus. Again, the technical equivalent seems straightforward: "We don't think we're going to need to support a second platform for at least five years, so this release can be built onthe assumption that we're supporting only one platform." (We'll call this Type II.B.)
The implication is that short-term debt should be paid off quickly, perhaps as the first part of the next release cycle, whereas long-term debt can be carried for a few years or longer.

Incurring Technical Debt

When technical debt is incurred for strategic reasons, the fundamental reason is always that the cost of development work today is seen as more expensive than the cost will be in the future. This can be true for any of several reasons.
Time to Market. When time to market is critical, incurring an extra $1 in development might equate to a loss of $10 in revenue. Even if the development cost for the same work rises to $5 later, incurring the $1 debt now is a good business decision.
Preservation of Startup Capital. In a startup environment you have a fixed amount of seed money, and every dollar counts. If you can delay an expense for a year or two you can pay for that expense out of a greater amount of money later rather than out of precious startup funds now.
Delaying Development Expense. When a system is retired, all of the system's technical debt is retired with it. Once a system has been taken out of production, there's no difference between a "clean and correct" solution and a "quick and dirty" solution. Unlike financial debt, when a system is retired all its technical debt is retired with it. Consequently near the end of a system's service life it becomes increasingly difficult to cost-justify investing in anything other than what's most expedient.

Be Sure You Are Incurring The Right Kind of Technical Debt

Some debt is taken on in large chunks: "We don't have time to implement this the right way; just hack it in and we'll fix it after we ship." Conceptually this is like buying a car—it's a large debt that can be tracked and managed. (We'll call this Type II.A.1.)
Other debt accumulates from taking hundreds or thousands of small shortcuts--generic variable names, sparse comments, creating one class in a case where you should create two, not following coding conventions, and so on. This kind of debt is like credit card debt. It's easy to incur unintentionally, it adds up faster than you think, and it's harder to track and manage after it has been incurred. (We'll call this Type II.A.2.)
Both of these kinds of debt are commonly incurred in response to the directive to "Get it out the door as quickly as possible." However, the second kind (II.A.2) doesn't pay off even in the short term of an initial development cycle and should be avoided.

Debt Service 

One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges.
If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too.

Attitudes Toward Technical Debt

Like financial debt, different companies have different philosophies about the usefulness of debt. Some companies want to avoid taking on any debt at all; others see debt as a useful tool and just want to know how to use debt wisely.
I've found that business staff generally seems to have a higher tolerance for technical debt than technical staff does. Business executives tend to want to understand the tradeoffs involved, whereas some technical staff seem to believe that the only correct amount of technical debt is zero.
The reason most often cited by technical staff for avoiding debt altogether is the challenge of communicating the existence of technical debt to business staff and the challenge of helping business staff remember the implications of the technical debt that has previously been incurred. Everyone agrees that it's a good idea to incur debt late in a release cycle, but business staff can sometimes resist accounting for the time needed to pay off the debt on the next release cycle. The main issue seems to be that, unlike financial debt, technical debt is much less visible, and so people have an easier time ignoring it.

How do You Make an Organization's Debt Load More Visible?

One organization we've worked with maintains a debt list within its defect tracking system. Each time a debt is incurred, the tasks needed to pay off that debt are entered into the system along with an estimated effort and schedule. The debt backlog is then tracked, and any unresolved debt more than 90 days old is treated as critical.
Another organization maintains its debt list as part of its Scrum product backlog, with similar estimates of effort required to pay off each debt.
Either of these approaches can be used to increase visibility into the debt load and into the debt service work that needs to occur within or across release cycles. Each also provides a useful safeguard against accumulating the "credit card debt" of a mountain of tiny shortcuts mentioned earlier. You can simply tell the team, "If the shortcut you are considering taking is too minor to add to the debt-service defect list/product backlog, then it's too minor to make a difference; don't take that shortcut. We only want to take shortcuts that we can track and repair later."

Ability to Take on Debt Safely Varies

Different teams will have different technical debt credit ratings. The credit rating reflects a team's ability to pay off technical debt after it has been incurred.
A key factor in ability to pay off technical debt is the level of debt a team takes on unintentionally, i.e., how much of its debt is Type I? The less debt a team creates for itself through unintentional low-quality work, the more debt a team can safely absorb for strategic reasons. This is true regardless of whether we're talking about taking on Type I vs. Type II debt or whether we're talking about taking on Type II.A.1 vs. Type II.A.2 debt.
One company tracks debt vs. team velocity. Once a team's velocity begins to drop as a result of servicing its technical debt, the team focuses on reducing its debt until its velocity recovers. Another approach is to track rework, and use that as a measure of how much debt a team is accumulating.

Retiring Debt

"Working off debt" can be motivational and good for team morale. A good approach when short-term debt has been incurred is to take the first development iteration after a release and devote that to paying off short-term technical debt.
The ability to pay off debt depends at least in part on the kind of software the team is working on. If a team incurs short-term debt on a web application, a new release can easily be rolled up after the team backfills its debt-reduction work. If a team incurs short-term debt in avionics firmware— the pay off of which requires replacing a box on an airplane— that team should have a higher bar for taking on any short-term debt. This is like a minimum payment--if your minimum payment is 3% of your balance, that's no problem. If the minimum payment is $1000 regardless of your balance, you'd think hard about taking on any debt at all.

Communicating about Technical Debt

The technical debt vocabulary provides a way to communicate with non-technical staff in an area that has traditionally suffered from a lack of transparency. Shifting the dialog from a technical vocabulary to a financial vocabulary provides a clearer, more understandable framework for these discussions. Although the technical debt terminology is not currently in widespread use, I've found that it resonates immediately with every executive I've presented it to as well as other non-technical stakeholders. It also makes sense to technical staff who are often all-too-aware of the debt load their organization is carrying.
Here are some suggestions for communicating about debt with non-technical stakeholders:
Use an organization's maintenance budget as a rough proxy for it's technical debt service load. However you will need to differentiate between maintenance that keeps a production system running vs. maintenance that extends the capabilities of a production system. Only the first category counts as technical debt.
Discuss debt in terms of money rather than in terms of features. For example, "40% of our current R&D budget is going into supporting previous releases" or "We're currently spending $2.3 million per year servicing our technical debt."
Be sure you're taking on the right kind of debt. Not all debts are equal. Some debts are the result of good business decisions; others are the result of sloppy technical practices or bad communication about what debt the business intends to take on. The only kinds that are really healthy are Types II.A.1 and II.B.
Treat the discussion about debt as an ongoing dialog rather than a single discussion. You might need several discussions before the nuances of the metaphor fully sink in.

Technical Debt Taxonomy

Here's a summary of the kinds of technical debt:
Non Debt
Feature backlog, deferred features, cut features, etc. Not all incomplete work is debt. These aren't debt, because they don't require interest payments.
Debt
I. Debt incurred unintentionally due to low quality work
II. Debt incurred intentionally
II.A. Short-term debt, usually incurred reactively, for tactical reasons
II.A.1. Individually identifiable shortcuts (like a car loan)
II.A.2. Numerous tiny shortcuts (like credit card debt)
II.B. Long-term debt, usually incurred proactively, for strategic reasons

Summary

What do you think? Do you like the technical debt metaphor? Do you think it's a useful way to communicate the implications of technical/business decision making to non-technical project stakeholders? What's your experience? I look forward to your thoughts.

Resources 

Definition of a Tech Lead

Good summary of a “tech lead” by James McGovern:
If you are in this role and want to live up to your title, then you need the following skills:
  • Accountable – The buck stops here, someone who can shoulder the responsibility without pointing fingers at others.
  • Adaptable – Life changes fast, if can’t change with the times, you’ll be left behind.
  • Approachable – their team can ask them questions and talk to them.
  • Attentive – they actually listen to their team and understand them.
  • Aware – they’re aware of what is going on around them instead of sticking their head in the sand.
  • Can type – No hen peck typists need apply in this industry.
  • Charismatic – People have got to want to listen to you.
  • Communicative – You’ve got to want to communicate with your team.
  • Competent – You’ve gotta know your stuff.
  • Confident – If you’re not confident in yourself, how is anyone else going to be?
  • Decisive – can make decisions themselves and be accountable for them.
  • Driven – You’ve gotta see the goal and go right after it.
  • Focused – You’ve gotta have the staying power to keep going and reach the goal.
  • Inspirational – this is the most important one for me! If you can’t inspire people, what are you doing?
  • Meticulous – The truth is in the details.
  • Nurturing – The test of a good teacher is when their students surpass them.
  • Resourceful – You’ve gotta be able to find the answers to the things you don’t know.
  • Technically minded – In this industry at least.
  • Understanding – If your team don’t think you understand them, they won’t bother trying to understand you.
As a leader, it’s your delegates that help build your success. Treat them like gold, and they will do the same for you. One non-programmer that can inspire 10 “average” programmers to greatness is worth more than one great programmer who can’t inspire their team to do more than meet their job requirements…

11/1/11

Creating Quality Assurance


by Brad Egeland

Wikipedia defines quality assurance as the systematic monitoring and evaluation of the various aspects of a project, service or facility to maximize the probability that minimum standards of quality are being attained by the production process.
In project management terms, quality assurance, or QA, is the sum of the planning and the implementations of the plans the project manager, the project team, and management does to ensure the project meets the demands of quality. The project manager must ensure that the proper QA processes and tasks are built into the project schedule using a PM software tool and viewer like Seavus’ Project Viewer.  Keep in mind that quality assurance is not something that is done only at the end of the project, but before and during the project.
In some organizations, the Quality Assurance department or another entity will complete the QA activities. Quality assurance is interested in finding the defects and then fixing the problems. There are many different approaches to quality assurance, depending on the quality system the organization or project team has adapted. There are really just two general types of quality assurance:
  • Internal QA. Assurance provided to management and the project team
  • External QA. Assurance provide to the external customers of the project
Preparing for Quality Assurance
There are three inputs the project manager and the project team will need to prepare for QA:
  • The quality management plan. This plan defines how the project team will implement and fulfill the quality policy of the performing organization.
  • Results of quality control measurements. Quality control tests will provide these measurements. The values must be quantifiable so results may be measured, compared, and analyzed. In other words, “pretty close to on track” is not adequate; “95 percent pass rate” is more acceptable.
  • Operational definitions. The metrics that define the project processes, their attributes, and units of measure are needed for QA.
Applying Quality Assurance
The QA department, management, or in some instances, even the project manager can complete the requirements for QA. Quality assurance can be accomplished using the same tools used for project planning:
  • Benefit cost analysis
  • Benchmarking
  • Flowcharting
  • Design of experiments
  • Cost of quality
Completing a Quality Audit
Quality audits are about learning. The idea of a quality audit is to identify the lessons learned on the current project to determine how to make things better for this project – and other projects within the organization. The idea is that one project manager can learn from the implementations of another project manager and vice versa.
Quality audits are formal reviews of what’s been completed within a project, what’s worked, and what didn’t work. The end result of the audit is to improve performance for the current project, other projects, or the entire organization.
Quality audits can be scheduled at key intervals within a project or they can come without warning, depending on your organization’s own internal policies or possibly the requirements of whatever contract you might be working on (i.e., government contract). And the audit process can vary depending on who is completing the audit: internal auditors or hired, third party experts.

Improving the Project
The lone output of quality assurance is quality improvement.
Quality improvement requires action to improve the project’s effectiveness. The actions to improve the effectiveness may have to be routed through the change control system, which means change requests, analysis of the costs and risks, and involvement from the Change Control Board – if one exists in your organization or on your program or project.

Information or this article was derived, in part, from Phillips’ book entitled, “PMP Project Management Professional Study Guide.”

Implementing Quality


by Brad Egeland

Once we have gone through the process of quality planning – as described in Part 2 of this series – we then move of to the act of implementing a quality policy for the organization.
Because planning is iterative, the quality planning sessions may need, and often require, several revisits to the quality planning processes. On longer projects, there may need to be scheduled quality planning sessions to compare the performance of the project in relation to the quality that was planned.

Creating the Quality Management Plan
One of the major outputs of quality planning is the quality management plan. This document describes how the project manager and the project team will fulfill the quality policy.
The quality management plan addresses three things about the project and the project work:
  • Quality control. Work results are monitored to see if they meet relevant quality standards. If the results do not meet the quality standards, the project manager applies root cause analysis to determine the cause of the poor performance and then eliminates the cause. Quality control is inspection orientated.
  • Quality assurance. The overall performance is evaluated to ensure the project meets the relevant quality standards. Quality assurance maps to an organization’s quality policy and is typically a managerial process. Quality assurance is generally considered the work of applying the quality plan.
  • Quality improvement. The project performance is measured and evaluated, and corrective actions are applied to improve the product and the project. The improvements can be large or small depending on the condition and the quality philosophy of the performing organization.
Identifying the Operational Definitions
Operational definitions, also known as metrics, are the quantifiable terms and values to measure a process, activity, or work result. An example of an operational definition could be an expected value for the required torque to tighten a bolt on a piece of equipment. By testing and measuring the torque, the operational definition would prove or disprove the quality of the product. Other examples can include hours of labor to complete a work package, required safety measures, cost per unit, and so on.
Operational definitions are clear, concise measurements. Designating that 95% of all customer service calls should be answered by a live person within 30 seconds is a metric. A statement that all calls should be answered in a timely manner is not.

Applying Checklists
Checklists are approaches to ensure work is completed according to the quality policy. It’s usually a list of activities that project team members or department workers will check off to ensure each task has been completed. Checklists can be quick instructions of what needs to be done to test a piece of code, create a document, or build a piece of equipment.  Or it can be questions that remind the developer to complete a task: “Did you test to verify that all output on the test report was accurate?”

Planning for Quality


by Brad Egeland

Planning for quality…seems logical, right?  But so many times we put too little time into the actual planning of the project that quality can get missed along the way.
Once the project manager has assembled the needed inputs, and evaluated the product description and project scope, he should get to work creating a plan on how to satisfy the quality demands. He’ll need to rely on the documentation created to date, his project team, and the project’s key stakeholder for much of the input. In addition, the project manager will use several different techniques to plan on meeting quality.
As planning is an iterative process, so too is quality planning. As events happen within the project, the project manager should evaluate the events and then apply corrective actions. This is a common PMI theme: plan, implement, measure, react – and document. Throughout the project implementation, things will go awry, team members may complete less-than-acceptable work, stakeholders will demand changes, etc.  All of these variables must be evaluated for their impact on project quality. What good is a project if it’s “completed” on time, but the quality of the deliverable is unacceptable? Technically, if the product is unacceptable, the project is not finished since it failed to meet the project scope. Let’s look at some tools and techniques the project manager will use to plan for quality.

Using a Benefit/Cost Analysis
Benefits should outweigh costs.
A benefit/cost analysis is a process of determining the pros and cons of any process, product, or activity. The straightforward approach, when it comes to project management, is concerned with the benefits of quality management activities versus the costs of the quality management activities. There are two major considerations with the benefit/cost analysis in quality management:

Benefit. Completing quality work increases productivity because shoddy work does not have to be redone. When work is completed correctly the first time, as expected, the project does not have to spend additional funds to redo the work.

Costs. Completing quality work may cost more monies than the work is worth. To deliver a level of quality beyond what is demanded costs the project additional funds. The types of quality management activities that guarantee quality may not be needed for every project.

Gold plating. The customer does not need or want more than what was requested. Gold plating is the process of adding extra features that may drive up costs and alter schedules. The project team should strive to deliver what was expected.

Applying Benchmarking Practices
Benchmarking, when it comes to quality project management, is all about comparing this project to another. Benchmarking is a technique to take what the project manager has planned or experienced regarding quality and compare it to another project to see how things measure up. The current project can be measured against any other project – not just projects within the performing organization or within the same industry.
Benchmarking allows the project manager and the project team to see what’s possible and then strive toward that goal. Benchmarking can also be used as a measurement against industry standards, competitors’ pricing, or competitors’ level of performance.

Creating a Flowchart
Technically, a flow chart is any diagram illustrating how components within a system are related. An organizational flow chart shows the bottom crew of operations up to the one person on top. A HVAC blueprint shows how the air flows through a building from the furnace to each room. Flow charts show the relation between components, as well as help the project team determine where quality issues may be present and, once done, plan accordingly.

Design of Experiments
The design of experiments approach relies on statistical what-if scenarios to determine what variables within a project will result in the best outcome. Design of experiments approach is most often used on the product of the project, rather than the project itself. Design of experiments is also used as a method to identify which variables within a project, or product, are causing failures or unacceptable results. The goal of design of experiments is to isolate the root cause of an effect and then make adjustments to that cause to eliminate the unacceptable results.

Considering the Cost of Quality
The cost of quality considers the expense of all the activities within a project to ensure quality. The cost of quality is broken into two major categories:

Cost of conformance to requirements. This approach is the cost of completing the project work to satisfy the project scope and the expected level of quality. Examples of this cost include training, safety measures, and quality management activities to ensure that quality is met.

Cost of nonconformance. This approach is the cost of completing the project work without quality. The biggest issue here is the money lost by having to redo the project work; it’s always more cost effective to do the work right the first time. Other nonconformance costs include loss of sales, loss of customers, downtime, and corrective actions to fix problems caused by incorrect work.

Preparing for Quality


by Brad Egeland

Project quality is a key determiner of customer satisfaction…which in turn is a key determiner for project success.  Therefore, nothing about quality should be taken lightly on the project.  Before a project manager can plan for quality, he must know what the quality expectations are. Specifically, what are the quality standards of the performing organization and which quality standards are applicable to the project? As part of the planning processes, the project manager and the project team must identify the requirements of planning, determine how the requirements may be met, and identify the costs and time demands to meet the identified requirements.
One of the key principles of project quality management is that quality is planned in, not inspected in. Planning for quality is more cost-effective than inspecting work results and doing the work over, or correcting problems to adhere to quality demands.
The project manager must consider the cost of achieving the expected level of quality in contrast to the cost of nonconformance. The cost of quality includes training, safety measures, and action to prevent poor quality. The cost of nonconformance can far outweigh the cost of quality: loss of customers, rework, lost time, lost materials, and danger to workers.

Determining the Quality Policy
Top management should define the quality policy. The quality policy of the organization may follow a formal approach such as ISO 9000, Six Sigma, or Total Quality Management (TQM), or it may have its own direction and approach to satisfying the demand for quality.
The project team should adapt the quality policy of the organization to guide the project implementation. This ensures the management of the project and the deliverables of the project are in alignment with the performing organization’s quality policy. In addition, the project manager should document how the project will fulfill the quality policy in both management and in the project deliverable.
But what if the performing organization doesn’t have a quality policy? Or what if two different entities are working together on a project and they use differing quality policies? In these circumstances, the project management team should create the quality policy. The quality policy, in these instances, will accomplish the same goals as a company’s quality policy: to define quality requirements and determine how to adhere to them.
Regardless of where the quality policy comes from – management or the project team – the project stakeholders must be aware of the quality policy. This is important because the quality policy, and associated quality methodology, may require actions that could lengthen the project schedule. For example, quality audits, peer reviews, and other quality-centric activities. In addition to the required time to fulfill the quality requirements, there may be additional costs incurred.

Reviewing the Project Scope Statement
Just as project quality management is focused on fulfilling the needs of the project, the scope statement is a key input to the quality planning process. Recall that the scope statement defines what will and will not be delivered as part of the project, as well as objectives regarding cost, schedule, and scope and all of these are built into your project schedule using a tool like Seavus’ Project Viewer. The deliverables, and the expectations of the customers, will help guide the quality planning session to ensure the customer requirements in regard to quality are met.

Reviewing the Product Description
While the project scope will define the initial product description, the product description may have supporting detail that the project manager and project team will need to review. Consider a project to create an apartment building. The requirements, specifications, and details of the building will need to be evaluated and reviewed since this information will, no doubt, affect the quality planning.

Reviewing the Standards and Regulations
The standards and regulations of each industry will need to be reviewed to determine that both the project plan and the plan for quality are acceptable. For example, a project to wire a building for electricity will have certain regulations it must adhere to. The relevance of the regulations must be planned into the project to conform to the requirements.

Reviewing Other Process Outputs
The project manager will need more than just the scope statement and the product description to plan for quality. The outputs of other processes will need to be evaluated for quality considerations. For example, procurement, may have special needs for contractors. The organization purchases products and services from vendors. If the vendors’ level of quality is unacceptable, the project can suffer, get off schedule, or result in failure.

Information for this article was derived, in part, from Joseph Phillips book entitled, “PMP Project Management Professional Study Guide.”

6/9/11

Il fantasma dell’acqua privata


Da Londra alla Bolivia. Così il mercato ha reso pragmatica ed efficiente la gestione dell’oro blu

L’acqua “diritto umano”, con rispetto parlando, è difficile bersela. Eppure c’è scritto nella risoluzione Onu del 28 luglio 2010, approvata con 122 voti a favore (tra cui quello italiano) e 41 astensioni, tutte motivate da esplicite perplessità di paesi che vanno dalla Danimarca al Botswana. La risoluzione “esprime profonda preoccupazione per i circa 884 milioni di persone prive di accesso all’acqua potabile e i più di 2,6 miliardi che non hanno accesso ai basilari servizi sanitari”. Da qui la conclusione che “l’acqua potabile e i servizi sanitari sono parte integrale della realizzazione di tutti i diritti umani”.

Ora, le parole sono belle, e quelle che descrivono un mondo coi fiumi di miele e le case di marzapane specialmente. Però, definire qualcosa un diritto non fa comparire per miracolo le infrastrutture dove le infrastrutture non ci sono, e non bagna – di per sé – le labbra agli assetati. Non fa miracoli, tra l’altro, quando le rotonde enunciazioni dei diritti sono contenute in una risoluzione non vincolante che, come scrive l’Ocse con tono talmente serio da apparire canzonatorio, “stabilisce che i governi dovrebbero garantire l’accesso all’acqua potabile, ma non dice come tale accesso dovrebbe essere garantito, né che dovrebbe essere gratuito”.

Dietro queste silenziose schermaglie tra istituzioni internazionali non c’è solo l’apparente incomunicabilità tra economisti e giuristi (o politici). Né si può ridurre tutto alla mera tensione tra il “vorrei ma non posso” dei diritti e il brutale “vuoi qualcosa? Compralo” dei cinici. Nel mezzo c’è una faccenda dannatamente concreta. I numeri dell’Onu sono veri e terribili: un sesto della popolazione mondiale beve poca acqua e sporca, e quasi la metà non è servita da alcun sistema fognario (e lasciamo perdere, per carità di patria, la depurazione dei reflui).

Da qui, la querelle sulla privatizzazione. Che è pura aggressione ideologica e immotivata contro i privati. Quando dovrebbe essere ricerca pragmatica di soluzioni che funzionino, se non in modo perfetto, almeno in modo accettabile. La prima e più banale osservazione è che, poiché l’acqua è generalmente gestita dallo stato, l’insoddisfacente livello di copertura è indice della non sempre straordinaria efficienza degli enti pubblici e dei decisori politici. Perché un primo punto su cui bisogna mettersi d’accordo è questo: l’acqua non è un “bene pubblico” nel senso specifico che a questa espressione danno gli economisti, cioè un bene il cui consumo sia “non rivale” e “non escludibile” quale, per esempio, la difesa nazionale. Può essere un bene pubblico nel senso che è di proprietà dello stato: ma allora è mera evidenza descrittiva. Può essere un “bene comune”, qualunque cosa significhi, come dice Stefano Rodotà nell’esercizio un po’ funambolico di immaginare “una forma di gestione comune” (sì, ma gli investimenti chi li decide? E i costi chi li paga?). L’acqua può persino essere “un grande dono di Dio che non può essere trasformato in merce”, come ha scritto padre Alex Zanotelli, ma il buon Dio non ci ha dato potabilizzatori, pompe, condotte, stazioni di sollevamento, depuratori e quant’altro. Ci ha detto che, volendo la bicicletta, dobbiamo pedalare, e pedalare costa fatica – o, in questo caso, denaro. L’acqua è, insomma, un “bene economico”, cioè scarso, e questo vale a maggior ragione per la fornitura del servizio che noi, semplificando, chiamiamo il diritto all’acqua. Il Padreterno, insomma, ci ha dato il diritto di abbeverarci al fiume e pisciare nel mare, ma se vogliamo che l’acqua potabile esca dal rubinetto di casa e che i nostri liquami non scorrano lungo le strade (con tutte le conseguenti esternalità negative), dobbiamo rivolgerci agli uomini. Dai e dai, e anche grazie al sostegno di istituzioni quali la Banca mondiale e l’Ocse, si è così arrivati alla “privatizzazione”, ossia al coinvolgimento – in varie forme – di attori privati nella realizzazione e gestione (anche commerciale) delle infrastrutture idriche e fognarie. Coinvolgimento che, ovunque nel mondo, presuppone un forte e attivo ruolo pubblico di regolazione e sorveglianza, che forse è meno sexy ma che nasconde l’hic Rhodus, hic salta di qualunque ragionamento serio.

Le forme di “privatizzazione” sono molto diverse tra di loro, e molto diversi sono i risultati, ma generalmente positivi. Per esempio, Cuba ha privatizzato l’acqua dell’Avana nel 2000, firmando una concessione venticinquennale con Aguas de la Habana (una sussidiaria del gruppo spagnolo Aguas de Barcelona). Nel suo libro “Acqua in vendita? Come non sprecare le risorse idriche” (Ibl Libri, pp. 174, 15 euro), Fredrik Segerfeldt passa in rassegna molte esperienze di privatizzazione nel mondo in via di sviluppo, osservando “nel mondo reale dobbiamo confrontare alternative imperfette e stabilire quale funziona meglio. Se mettiamo a confronto la distribuzione d’acqua pubblica e quella privata, i fatti dimostrano che l’alternativa privata, in generale, è sempre stata molto superiore”. Perfino quando non sono stati raggiunti i risultati sperati – e sovente ciò è accaduto per colpa di una cattiva regolazione – le cose sono migliorate rispetto alle precedenti gestioni pubbliche. In Bolivia – paese che dopo l’avvento di Evo Morales nel 2006 ha dichiarato guerra alle gestioni private – “nel 2003, in un sondaggio condotto dal governo boliviano, Aisa (il gestore idrico di La Paz ed El Alto) venne votata come la migliore azienda del settore”. In meno di un decennio, Aisa ha allungato le condutture di 1.430 chilometri, dando accesso all’acqua corrente al 98,5 per cento della popolazione e allacciando 373.000 persone in più all’acquedotto e 435.000 alla fognatura. Nelle nazioni povere, infatti, l’acqua non è un diritto in nessun senso del termine: e, in generale, il coinvolgimento di attori privati ha consentito di allargare le opportunità d’accesso. Alzando le tariffe per chi già era allacciato alla rete (generalmente i ceti urbani medio-alti), ha potuto raggiungere le periferie più povere, che in precedenza si rifornivano presso venditori d’acqua più o meno legali, virtualmente in assenza di controlli sanitari e soprattutto, dice Segerfeldt, pagandola “in media 12 volte più cara di quella che avrebbero in rete, e in alcune occasioni ancora di più”.

Straordinario è, in questo senso, il caso della Guinea. Fino al 1989, solo il 20 per cento della popolazione urbana poteva aprire il rubinetto: dodici anni dopo, grazie all’avvio di una partnership pubblico-privato, erano diventati il 70 per cento. Naturalmente, questa evoluzione non è stata priva di costi: la tariffa è lievitata da 15 centesimi a quasi un dollaro per metro cubo. Ma la domanda cruciale è: chi ha subito il rincaro? Principalmente, il 38 per cento della popolazione urbana nelle dieci città già allacciate ai tubi: l’aumento tariffario è stato invece un’opportunità per tutti gli altri, cioè il 70 per cento degli abitanti di 18 città, che oltre tutto hanno goduto dell’ulteriore esternalità positiva della maggiore igiene sulla salute pubblica. Un successo, va da sé, non nasconde gli insuccessi: per esempio il caso clamoroso di Buenos Aires, bandiera del movimento anti privatizzazione, con l’annullamento nel 2006 della concessione affidata ad Aguas Argentina nel 1993.

Dietro lo scontro tra i privati e il governo ci sono tante brutte vicende – da un contratto di servizio poco chiaro fino a episodi di corruzione – ma il tracollo venne causato da ragioni di politica monetaria, con l’impossibilità per il gestore di adeguare le tariffe (espresse in valuta argentina) ai costi (perlopiù in dollari). Quella di Buenos Aires è anche una storia di cattiva regolazione. Tutto ciò non nasconde i clamorosi risultati raggiunti: in pochi anni vennero allacciati più di 3 milioni di nuovi utenti, l’85 per cento dei quali nelle zone più povere. Il “fallimento”, insomma, va messo nella prospettiva della crisi argentina, e in ogni caso ha lasciato in eredità un sistema idrico migliore di quello di cui i privati si erano fatti carico.

Nel “nostro” mondo, naturalmente, le cose stanno diversamente. Pressoché tutti hanno l’acqua corrente, e il problema è semmai di altro tipo: in casi patologici l’“oro blu” non rispetta la prescrizioni sui livelli di certi inquinanti (come l’arsenico, oggetto di molte deroghe contestate all’Italia dall’Unione europea). Mentre è “fisiologico” lo stato di degrado delle condotte e l’insufficienza del servizio di depurazione. Queste sono le ragioni per cui è necessario, anche in Italia e nel mondo industrializzato, mobilitare investimenti. Come è accaduto dove ci si è provato: il Regno Unito, ha privatizzato le sue dieci “Water Authorities” nel 1989, affidando i compiti di regolazione a un organo indipendente, Ofwat, ha avuto risultati lusinghieri. Secondo la Banca mondiale, nei sei anni successivi gli investimenti sono cresciuti da 9,3 a 17 miliardi di sterline, sono stati raggiunti standard ambientali e sanitari più stringenti, e la qualità dell’acqua è migliorata. E se è vero che Parigi ha recentemente deciso di ripubblicizzare l’acqua (dopo 150 anni di gestione privata), è anche vero che diverse nazioni, specialmente nell’Europa dell’est, hanno seguito con soddisfazione la strada opposta, mentre nel mondo in via di sviluppo il numero di persone servite da gestori idrici privati è esploso da 6 milioni nel 1991 a 160 milioni nel 2007.


Ed è qui che emerge la superiorità, se non del privato, almeno di un modello che consenta, volta per volta, di chiamarlo in campo oppure no, e di indurre pure il pubblico a comportarsi secondo criteri “privatistici”. Ci sono tre aspetti di grande importanza. 
Uno riguarda gli incentivi: un’impresa privata è spinta a fare profitti, e quindi è naturalmente indirizzata a tagliare, non gonfiare, i costi (dato un certo livello di prestazione). Una buona regolazione – che è essenziale poiché l’infrastruttura idrica è un “monopolio naturale” – può trasferire parte di questo beneficio al consumatore. Viceversa, un soggetto pubblico, che non corre il rischio reale di sanzioni o di perdere l’affidamento, può diventare strumento clientelare nelle mani dei politici. Secondariamente, la dialettica tra regolatore e regolato tende a essere più efficace e trasparente se essi sono distinti: quando invece entrambi vengono nominati dallo stesso soggetto, allora il loro confronto tende a sfumare in un conflitto di interessi il cui punto di caduta è, probabilmente, la cattura del regolatore. Terzo, data la crescente complessità del settore idrico – che non è più fatto di soli tubi – i privati, per dimensione e vocazione, in genere sanno “fare meglio” il proprio lavoro. Possono esserci (e ci sono) casi di eccellenza nel pubblico e fiaschi clamorosi nel privato, ma gli uni e gli altri è facile che siano l’eccezione, non la regola.

Tutto ciò ha di per sé poco a che fare coi meccanismi tariffari. Si può affidare il servizio idrico a un privato oppure al pubblico, e praticare in entrambi i casi le politiche tariffarie più diverse. In generale, è buona prassi coprire la maggior parte dei costi (possibilmente tutti) con la tariffa, limitando al massimo i contributi in conto capitale da parte degli enti pubblici affidatari. Questo perché, da un lato, l’obbligo di soddisfare le spese coi ricavi “commerciali” è di per sé un incentivo a comportarsi bene; dall’altro perché, dal punto di vista redistributivo, è opportuno che chi consuma, paghi; dall’altro ancora perché far pagare un prezzo inferiore al necessario induce il consumatore allo spreco. Quali alternative sono possibili? Dice il referendario Corrado Oddi, intervistato da Luca Martinelli (autore anche di un intelligente pamphlet pro referendum, “L’acqua (non) è una merce”, Altreconomia, pp. 151, 12 euro): “Facciamo scendere in campo la finanza pubblica e la fiscalità generale”. Ma, in questo modo, si innescano distorsioni le più pervese. Antonio Massarutto, nel suo bel libro “Privati dell’acqua?” (Il Mulino, pp. 252, 16 euro), spiega che “se la tariffa non si fa carico di ricostituire il capitale iniziale, vuol dire che la generazione dei nonni e quella degli adulti omettono di pagare qualcosa, il cui costo ricadrà sui figli”. Infatti, l’infrastruttura idrica ha una vita tecnica molto lunga – a volte nell’ordine del secolo – ma nel frattempo deve essere manutenuta, e alla fine ricostruita. Sempre che gli investimenti vengano fatti: se si vuole impedire alla tariffa (o alla spesa pubblica) di crescere, basta non investire. Ma bisogna essere consapevoli delle conseguenze.

A volte, comunque, aumentare i ricavi da tariffa significa soltanto costringere tutti a pagare, essere meno tolleranti coi morosi. Anche la riscossione dei crediti è un’attività che i privati sanno (e vogliono) fare meglio.

Le obiezioni ai rischi delle “privatizzazioni” rasentano il paradosso: come scrive Franco Bassanini nell’introduzione al libro di Claudio De Vincenti e Adriana Vigneri (“I servizi pubblici locali tra riforma e referendum”, Astrid, pp. 168, 18 euro), “se un ente locale non è capace di indirizzare e controllare, non sarà neanche capace di indirizzare, controllare e gestire”.

Parte del problema sta nella confusione più o meno deliberata tra “privato” e “profitto”, come se “guadagnare sull’acqua” fosse immorale. Il fatto è che qui non ci sono né il tempio né i mercanti: la “privatizzazione” non è il cavallo di Troia del profitto, ma lo strumento per attirare imprese specializzate. In presenza di una buona regolazione, la capacità di fare profitti è indice anzitutto di efficienza, e quindi dello sforzo di mantenere bassi i costi operativi (e magari ridurli). Inoltre, profitti “troppo alti” sono chiaramente visibili al regolatore, che può intervenire – nei modi e nei tempi opportuni – per riallineare la tariffa (attraverso il metodo del “price cap”). Viceversa, un’impresa pubblica formalmente in pareggio, in assenza della spada di Damocle della gara, potrebbe essere semplicemente spendacciona, e trasformare l’extraprofitto monopolistico – anziché in un luminoso attivo di bilancio – nell’elargizione opaca di commesse a fornitori amici o nel mantenimento di un organico sovradimensionato (ciò che gli economisti chiamano x-inefficiency).

In ultima analisi, insomma, a dispetto della comprensibile retorica che desta, l’acqua richiede di stare coi piedi per terra. Qualunque decisione non riguarda solo le tasche dei cittadini, ma anche il rapporto tra lo sviluppo umano e l’ambiente. E’ proprio l’attenzione all’impatto ambientale del ciclo dell’acqua che ha spinto un’associazione ambientalista come gli Amici della Terra a schierarsi contro il referendum del 12-13 giugno: “Una buona parte degli obiettivi di tutela ambientale delle acque dipende dagli investimenti per colmare il deficit depurativo e per un efficace funzionamento del ciclo integrato dei servizi idrici”. In sostanza, l’acqua ha bisogno di attenzione, discrezione e pragmatismo. Lo scontro tra pubblico e privato è in parte fuorviante, ma sarebbe sbagliato sottrarsi.

Molte città in giro per il mondo, dall’Avana fino a Londra, si sono affidate con soddisfazione a gestori privati. Chiedere la piena privatizzazione (come ha fatto l’Ocse per il nostro paese) forse è politicamente irrealistico. Ma chiedere in Italia che i capitalisti dell’acqua siano trattati almeno con lo stesso rispetto che gli è riservato a Cuba è pretendere troppo?

3/29/11

Dedicato alle aziende/3: nota a margine

Dedicato alle aziende/3: nota a margine: "

Avevo già scritto:


Se sei un’azienda, o un cliente privato, e stai leggendo qui, stai cercando un web developer, non una figura legata in qualche modo alla comunicazione. Non hai perciò alcuna necessità specifica di sapere come mi muovo nel campo della comunicazione online.


Quello che non sapevo è ciò che è riportato in un articolo del Sole 24ore:


L’articolo 8 dello Statuto dei Lavoratori, richiamato anche dal Codice della Privacy, vieta qualsiasi indagine, anche pre-assuntiva, non solo sulle opinioni del lavoratore, ma anche su qualsiasi fatto che non sia rilevante ai fini della valutazione dell’attitudine professionale. La ricerca di informazioni personali sul candidato tramite Facebook è quindi da considerarsi illecita, ma è anche pericolosa per chi la effettua, dal momento che la violazione dell’articolo 8 dello Statuto dei lavoratori è sanzionata penalmente.


Azienda avvisata etc.

"

10/27/09

Java Hashing

Java Hashing: "Every Java object has two very important methods i.e. hashCode() and an equals() method. These methods are designed to be overridden according to their specific general contract. This article describes why and how to override the hashCode() method that preserves the contract of HashCode.

Contract For HashCode The contract for hashCode says‘If two objects are equal, then calling hashCode() on..."



(Via Javalobby Front Page.)

10/26/09

The Problem With iPhone Killers…

The Problem With iPhone Killers…: "Here we are again. The hype leading up to a new mobile device is reaching a fever pitch. Motorola’s Droid sounds, looks, and by some accounts, is impressive. As such, everyone’s favorite superlative is being thrown out there once again: ‘iPhone killer.’ Of course, we’ve heard this before — maybe a dozen times. The BlackBerry Storm was the iPhone killer, the Palm Pre was the iPhone killer, the G2, etc. Not only does the iPhone still survive, it thrives. Why?"



(Via .)

10/25/09

Article:Modular Java: Static Modularity

Article:Modular Java: Static Modularity: "Modularity is an important aspect of large Java systems. Build scripts and projects are often split up into modules in order to improve the build, but this is rarely taken into account at runtime. This second part of the Modular Java series discusses static modularity, the creation of bundles, how to install them into an OSGi engine and how to set up (versioned) dependencies between bundles. By Alex Blewitt"



(Via InfoQ.)

My IT-blog » Dependency Injection with Google Guice by example

My IT-blog » Dependency Injection with Google Guice by example: "In this blogpost, I’ll explain Dependency Injection with Google Guice through a lot of examples. Hope you like it."



(Via My IT-blog.)

x86 Assembly for C Programmers 1 : endeavormac4

x86 Assembly for C Programmers 1 : endeavormac4: "Introduction
I’m writing a series of tutorials on x86 assembly for C programmers who are already familiar with many of the basics of programming and computing. The assembly tutorials available online just aren’t doing it for me, and I need something organized the way I think, on the topics I’m interested in, presented in a way which make comprehensive understanding easy. I’ll do the work, go find the answers, and then drop everything here for you to enjoy."



(Via endeavormac4.)

10/24/09

javamelody - Project Hosting on Google Code

javamelody -

Project Hosting on Google Code
: "The goal of JavaMelody is to monitor Java or Java EE applications servers in QA and production environments. It is not a tool to simulate requests from users, it is a tool to measure and calculate statistics on real operation of an application depending on the usage of the application by users.

JavaMelody is opensource (LGPL) and production ready: in production in an application of 25 person years. JavaMelody is easy to integrate in most applications and is lightweight (no profiling and no database)."


10/21/09

Refactoring SQL Applications - O'Reilly Media

Refactoring SQL Applications - O'Reilly Media: "Refactoring SQL Applications
ByStephane Faroult, Pascal L'Hermite
Publisher:O'Reilly Media
Released: August 2008
Pages: 304"



(Via .)

10/18/09

Reduce Linux power consumption, Part 2: General and governor-specific settings

Reduce Linux power consumption, Part 2: General and governor-specific settings: "This three-part series is your starting point for tuning your system for
power efficiency. In Part 2, follow a step-by-step guide on the general
settings of the Linux CPUfreq subsystem and get more details on the five
in-kernel governors -- performance, powersave, userspace, ondemand, and
conservative -- and their settings."



(Via developerWorks : Linux : Technical library.)

Learn Linux, 101: File and directory management

Learn Linux, 101: File and directory management: "You've probably heard that everything in Linux is a file,
so start on the right path with a solid grounding in file and directory
management -- finding, listing, moving, copying, and archiving.
You can use this material in this article to study for the LPI 101
exam for Linux system administrator certification, or just to learn for fun."



(Via developerWorks : Linux : Technical library.)