11 Ground Rules For Meeting Behaviors

While recently reading C. Elliott Haverlack's new book, Unbundle It, I found his 11 ground rules for meeting behaviors to be particularly helpful:

1. Arrive on time.
2. Be respectful of other attendees.
3. No phones or computers if at all possible.
4. No leaving the meeting or getting up to walk around until scheduled breaks.
5. No eating unless during working meal meetings (consuming beverages as appropriate is acceptable).
6. No side conversations.
7. Good posture.
8. Listen intently (even if you don't want to).
9. Ask questions at the appropriate time.
10. No filibustering.
11. Take notes.

Artist Island

Once there was an island called Artist Island. The people on this island made a very good living by gathering stones from Stone Island, forming them into stunning jewels and selling the jewelry to people in the Land of Festivals. At first, people from Artist Island visited the Land of Festivals to see what kind of jewelry would be popular and then scouted out the right kinds of stones on Stone Island. But that was not a very efficient use of the time of these excellent artisans, so after a while the people from Stone Island were asked to bring their stones to Artist Island. Later, to further improve efficiency, the Stone People were asked to deliver the finished jewelry to the Land of Festivals. Since the Stone People were now the ones in contact with the Festival People, they became responsible for ordering the jewelry as well.

The people of Artist Island continued their search for efficiency. It took a long time to shape a pile of stones into a pile of jewels, and by the time a pile was done, the Stone People complained that the designs were out of date. So the artisans learned about Lean and decided to reduce work-in-progress. They worked on stone piles for no longer than two weeks, and brought smaller piles of jewels to the boat dock for shipment to the Land of Festivals.  However, the transport boats were still quite large and took some time to fill up, so it still took a long time for jewelry to get to the Festival People, and the designs were still out of date.

Then the Stone People came up with an idea. If they invested in smaller boats, they could deliver jewelry to the Land of Festivals in much smaller batches, shortly after it was made. Gradually they switched from large boats to small boats, and as they did, they started using the same small boats to deliver stones to Artist Island. Now a stone could be dug out of a mine, taken to Artist Island, formed into a jewel and delivered to the Land of Festivals in about a month. The jewelry designs were much more up-to-date, and sales improved.

But there was still a lot of unsold jewelry in warehouses in the Land of Festivals, because sometimes the jewels had flaws and sometimes the artisans didn't understand what the Stone People were asking them to make. Quite often the jewelry was boring because the Stone People weren't aware of the many marvelous kinds of jewels that were possible, so they didn't order many interesting designs.

The Earthquake
About this time an earthquake shifted the rocks holding water in the lake, and the water level receded.  Artist Island became a peninsula connected to the mainland. Some enterprising artisans decided to walk to the mainland and talk to the Festival People. They discovered that the Festival People didn't really like their jewelry designs very much, and so the artisans went back home and produced some new designs. After a few trips, they learned more and more about the festivals, their timing, their themes, and the kind of jewels that would be best for each one. They began to produce jewelry specially designed for each festival, and sales soared.

Of course, the artisans weren't using their time quite so efficiently anymore, because some of the best craftspeople spent part of their valuable time walking over to the mainland and talking to the Festival People. But then again, contact with customers energized the artisans, and they brought their enthusiasm back to Artist Island. The new designs were wildly popular, so none of them ended up stored in a warehouse. Thus the people of Artist Island were able to sell more jewelry and charge higher prices than before.

The artisans found that the Festival People were looking for unique jewels, so they asked the Stone People to look for new kinds of stones. But the new stones that the Stone People brought were not suitable for forming into jewels, and the artisans began to wish they had kept a few of their old boats so they could go and look for new stones themselves. One day some of the artisans went exploring their new peninsula and discovered a shallow sandbar connecting Artist Island to Stone Island. So they were able to wade over to Stone Island to help the Stone People look for better stones.

Because they knew what they were looking for, the artisans soon discovered new types of stones that could be easily formed into jewels. Actually, the new stones were much bigger than the previous ones -- they barely fit in the small boats -- so the Stone People had ignored them. The large stones gave the Artist Island people a novel idea: perhaps they could make cups and bowls from the new stones. Several different kinds of stones were brought to Artist Island and artisans eagerly tried their hand at making household items. This turned out to be easier than the intricate work of making jewelry, so even apprentice artisans were able to shape the new stones. The Festival People loved the new dishes and bought many pieces in addition to the jewels they always enjoyed.

Of course, the artisans weren't using their time quite so efficiently now that some of the best craftspeople were working with the Stone People as well as the Festival People. But then again, dishes involved less intricate work so more items could be produced and it was much easier to avoid flaws. Furthermore, the Festival People were eager to buy every single item the artisans could produce. No longer was finished work gathering dust in warehouses. Thus the artisans were able to make and sell many more products than before. Finally, since the household items were considered a necessity, business remained good even during tough economic times.

The New Landscape
Let’s take a tour of Artist Island a few years after the waters receded and turned it into a peninsula. The former island has three different kinds of artisans. First of all there are the enterprising artisans who learned to empathize with customers and look for new stones to shape in novel ways to solve customer problems. They are deeply engaged in their work and have created tight feedback loops so they can continue to develop products that customers love and bring innovative new stones to the market.

This group of artisans has revised the definition of efficiency.[1] They don’t worry too much about resource efficiency -- that is, keeping every artisan busy. They focus on flow efficiency -- that is, keeping each stone moving from Stone Island all the way to customers in the Land of Festivals with as little delay as possible. They have found that with greater flow efficiency, they get higher quality, more rapid customer feedback, and thus they are more likely to make products that delight customers. The enterprising artisans are doing very well.

But not everyone on Artist Island noticed that the waters receded, or if they noticed, they were not eager to abandon their comfortable routines. The traditional artisans believe in resource efficiency -- that is, making the most efficient use of their valuable time. So they continue to receive boatloads of stones from the Stone People, form them into the kind of jewels they are asked to make, and send the jewelry to be sold in the Land of Festivals. It’s not their problem if the Stone People order the wrong jewels, or if the boats are so large that their work is out of date by the time it reaches the Land of Festivals, or if half of their jewelry ends up in warehouses, unused by the Festival People. Their job is to deliver what they are asked for in a timely manner, and to continually reduce their costs.

Of course, the work is not very challenging and it’s difficult to get enthusiastic about making piles of jewelry that no one is likely to use. Because of this, many traditional artisans are leaving to join the enterprising artisans, attracted by the opportunity to think for themselves, the challenge of improving their artistic skills, and the satisfaction of seeing their work appreciated by the Festival People.

There is a third area of Artist Island -- one that wasn't mentioned earlier -- an area that has been around ever since stones began to be used for practical items. Here we find the parts-makers, artisans who form stones into parts for automobiles and airplanes and medical devices and control systems and things like that. They make up almost half of the population of Artist Island. The parts-makers work with vehicle and device designers to make sure their parts fit and operate properly. Recently they have learned a few things from the enterprising artisans, such as focusing on flow efficiency (moving stones through their work area without delay), understanding the needs of their customers (both the device designers as well as device customers), and constantly looking for new stones that can better meet these needs.

The Future
As the years go by, the enterprising artisans will move to the mainland to work side-by-side with the Festival People. The parts-makers will also migrate to the mainland and join forces with the device designers. All that will be left on the former island are the cost centers housing traditional artisans, but even these will gradually shrink and eventually disappear. Because in the end, while the talent of the artisans will remain essential, Artist Island will not matter anymore.

Navigating the New Landscape
We have spent a lot of time over the past decade working to make life better on Artist Island (a.k.a. Software Development Land). We promoted Lean principles such as small batches and steady flow and quality at the source. But over the past few years we have watched the waters recede and marveled as the island turned into a peninsula. The best and brightest of the artisans have abandoned the boat system and learned to talk directly with customers, work as partners with other disciplines, and seek out new approaches to solving problems.

We have written three books about Artist Island, but we couldn't write a fourth, because the island has largely disappeared. In its place is a new landscape, one in which integrated product teams are expected to ask the right questions, solve the right problems, and deliver solutions that customers love. So we wrote our fourth book -- The Lean Mindset: Ask the Right Questions -- about thriving in the new landscape, a land without islands, a land that doesn't have quite enough artisans, a land that’s full of endless possibilities.
_____________________________
Footnote:
[1] Thanks to Niklas Modig and Pär Åhlström, for introducing us to these two viewpoints on efficiency. See their excellent book -- This Is Lean: Resolving the Efficiency Paradox.

How Do You Manage a CIO?

I was listening to a pair of Chief Information Officers (CIOs) discuss the unusual problems they faced on a daily basis and how these difficult issues limited their future career options. From their perspective, they could not satisfy the myriad conflicting client demands on their limited IT resource pool without forcing them to always be the bad guy/girl in someone's eyes.

What I found most interesting about this and other conversations with CIOs was not the complexity of the job. Everyone knows it's a tough one. The shiny gem of truth was that the CIO job is not the end game plan for most people in the role. In retrospect, I realize I have yet to meet a CIO who sees their current job as the top rung in their ladder of career aspirations. Which makes managing a CIO an interesting challenge. If you were a CIO's boss, how would you manage her or him?

Standard HR doctrines aside, there are some unique aspects to the role and the CIO's future ambitions may influence their current behaviour. For example, IT organizations deliver tools to improve the business. Sometimes they build them from scratch, often they integrate vendor products, and sometimes they simply manage the vendor contract. But where does the CIO see her or his personal future? Building from scratch means a larger internal department; some CIOs find that approach appealing because it can translate into more power and influence inside their organizations.

Other CIOs see their next role in the vendor world. Maybe they want to go work for that exciting world-wide software company that makes your ERP system. Or perhaps they are pining for the new wave excitement of Google. Either way, the business choices they make in their current role may be tainted by their aspirations for a future role. IT procurement decisions may be biased towards the vendor organization where the CIO sees their next job.

The CIO who wants to stay within the organization but move to a line-of-business role may have other biases. They might be focusing an inordinate and inappropriate amount of time and effort on a user department to the detriment of other departments. Unbalanced emphasis of IT support to a favoured line-of-business can easily lead the strategic IT mission astray.

So imagine yourself as the CIO's boss. How do create filters to detect these biases and behaviours? You can't win an argument about the technical aspects of a decision, because that's the CIO's realm of subject matter expertise. But you can test for bias before you hire any CIO. As part of the selection process, ask CIO candidates pointed questions about their future ambitions. Ascertain their goals beyond the CIO job. Do they see themselves eventually joining a vendor or moving to an IT client role? How long does the candidate see himself or herself remaining as a CIO?

Another solution lies in building a stewardship (governance) model for IT. An effective stewardship model ensures the IT decision-making lies in the hands of the business and the CIO's role is to facilitate the process. Biases are easy to spot when the business wants to go one way and the CIO is going elsewhere. If business leaders prioritize projects, CIO preferences must be justified by facts or they will fail.

You can't be sure the stewardship model eliminates all biases. But a robust benefits realization process is another key checkpoint. Have you built a project management process that ensures benefits are tracked and measured against promises made in the original business case? Benefits realization forces the CIO to ensure project commitments match results. If not, there is a failure appreciation moment - an opportunity to learn from mistakes. Is the strategic mission of the organization aligned with the CIO’s personal mission?

The best way to ensure a CIO’s heart and mind are in line with the organizational vision is ask the CIO to craft an IT strategy through collaboration and consensus with business partners. Don’t let IT write the strategy in splendid isolation. Set clear expectations requiring broad-based contributions. Assess the CIO’s ability to work together with all IT stakeholders. Once the plan is published, measure the IT department's performance against the strategic business goals - not the technology goals.

CIOs may always complain about how hard their job is. But I think the person with the much harder job is the CIO's boss. Their challenge is to give him/her a hope for the future. What is the personal end game plan for the CIO and does it match the organization’s needs? Successful CIOs need a glimmer of career opportunity leading to the next step of the ladder within your organization. Groom the CIO to become the VP of Administration, or COO, or CEO. Without internal opportunity, the CIO will create their future elsewhere.

~

Any IT Organization Structure Is Ephemeral

In the process of introducing a new organization change a few years ago. One of my staff took me aside and said she understood why I had to make the changes, but she didn't really like the affect it had on her. I told her not to worry, because no IT organization structure is permanent. If she didn't like our current organization, I asked her to be patient and wait for the new one. I was already thinking about the next organization change before I had completed the latest one.

Organization structure exists to solve a problem. Once that problem is solved, it is probably time to change the organization again because there are new problems and new opportunities. The shelf life of any major effective IT organization structure is two years. Anything beyond a couple of years means IT has stagnated. External changes in the form of new technologies, or internal changes driven by new problems have arisen and the IT organization structure has to change to survive.

Think about implementing an ERP system. The sheer scope of the project typically consumes the full attention of everyone in the IT organization. The wise CIO creates an organization structure dedicated to ensuring the success of the project. The ERP becomes priority #1 by virtue of the size and impact of the implementation.

But once the ERP is implemented, the IT organization's attention has to shift. Expectations of IT change from the implementation of one big project to a plethora of follow-on projects. The organization's emphasis shifts from the management of a big bang strategic project to the management of a portfolio of tactical projects. To succeed with the new emphasis, the perceptive CIO creates a new organization structure.

This constant change approach can be difficult for some external groups to understand. For example, HR never likes organization changes. Not because it means more work for them, but because it means turmoil in the institution. Their job is to promote stability and constant IT change does not fit the typical HR model. Across the organization, most departments are not compelled to change nearly as rapidly as the IT department. External and internal change vectors are less common in departments like accounting or procurement.

But the fundamental rules of IT change constantly. Working in IT is like working in an accounting world where the generally accepted accounting principles (GAAP) change every year. If GAAP changed every couple of years in the real world, then the accounting department would have to re-organize much more often. That is what makes IT organization changes so special. Our rules change almost daily. We can't afford to wait. The world of technology passes us by if we don't have the right people focusing on the right things. We get stale, old, and unwanted pretty quickly if we aren't structured to take advantage of the latest and greatest technologies.

Value generation from new systems-based processes or market-grabbing technology-driven innovation can only come from nimble IT organizations. Agility in IT comes from a simple willingness to change everything, especially the organization structure. Organizations get value from information systems organization that can turn on a dime.

The external IT environment has already changed from the time you started reading this article. Have you thought about what that means to your IT department's structure? If you aren't already thinking about your next IT organization change you should be thinking about your next job ... maybe in accounting?

~

"To improve is to change, to be perfect is to change often"

The current business environment is very volatile, things are always changing. Companies need to be able to change quickly in order to keep up with the market, or even better, in order to drive the market.

Winston Churchill said "To improve is to change, to be perfect is to change often". Another interesting quote about change comes from Charles Darwin, he said "It it snot the strongest of the species that survive, not the most intelligent, but the one most responsive to change".

Organisational change management is something that not many professionals, including senior executives, know how to deal with it. I have encountered one too many executives that think that training is all there is to change management.

Wikipedia defines change management as an approach to shift organisations or individuals from a current state to a future desired state. It is an organisational process aimed at helping members of the organisation to embrace, or even desire, change in their business environment.

Change management uses structures and tools to control an organisational change effort. The goal is to maximise benefit and to minimise impact on workers to avoid distractions.

Responsibility for change management lies with executives and managers. They are responsible for introducing change that brings about improvement in a way that employees can cope with.

One classic mistake in change management occurs when managers spend months working on a change process and then expect everyone to accept it. Change needs to be gradual but constant.

John Kotter is a well regarded author of change management books. He recommmends the followwing steps for successful change.

•  Increase urgency. Explain and lead others into accepting and desiring the change.

• Build the guiding team. Gert the right people with time, commitment and the necessary skills to achieve the desired future state.

• Get the vision right.

• Communicate for buy in. Communicate the change often with the objective to get buy in. You want people to desire the change and see it as positive to their circumstances. Make communication simple and straight to the point. Although communication is important, getting the balance right is vital so you will not be overbearing and bore everyone to the point they don't want to hear about it.

• Empowerment actions. Senior management must empower  change agents into action, remove obstacles and do all they can to  support the process.

• Create short term wins. Gradual change is ideal and easier to process. Constant and positive change minimises the impact on the organisation and keeps the moment going.

• Don't let up. Long change process can be hard to achieve. Keep everyone motivated and working towards achieving the next milestone. Gradual change that can be achieve in bite-size chunks will keep everyone motivated and moving towards the final objective.

• Make change last. Make change part of company culture, employ workers that embrace change and always want to achieve new heights.

Business change is not only necessary but it is vital for businesses to survive in volatile business environments.

How to loose your job by being a good manager

If you have done any formal eduction in management and leadership you will know that these terms are different and have profound practical differences.

Let me give you an example. I once worked for an IT manager who was a very good manager. His planning skills were great, fantastic attention to detail, he was organised, he was able to get the team organised and he controlled the activities quite well, ensuring that deadlines were met and the department operated within the budget constraints. These are the basic functions from a manager, planning, organising and controlling.

This manager was always prepared for his meetings and he was very proud of being logical and getting people on his side using his critical thinking and argumentative skills. However what he didn't realised that he didn't win every argument because people agreed with him, instead, he was always right because nobody could argue him out of his views, even if they didn't agree. He was actually very good at presenting his views and getting others to "agree" with him.

I must confess that I thought that working under him was great. The team was producing good outcomes and delivering projects on time and within budget.

However something was happening in the background. Other mangers and directors were getting resented of
his approach and attitude. He was always right and never prepared to give up on his views, even when most people had differing opinions. To cut a long story short, he is a now a very happy man who got a very big redundancy package and, given his age, has retired.

He had very good management skills but very poor leadership and people management skills. His strong management skills, and lack of leadership, git him to a redundancy.

So what went wrong. I observed the entire thing trying to learn what to do and what not to do. Working under him I learned a lot about management and also learned a lot how not to deal with people.

Management skills are very important and managers need to be strong when necessary. However people need to be truly on the manager's side rather than compelled to do what he says just because he is always right.

So what are the differences between management and leadership? I have come across many articles that explain the difference. In his 1989 book “On Becoming a Leader,” Warren Bennis composed a list of the differences, as follows:

– The manager administers; the leader innovates.
– The manager is a copy; the leader is an original.
– The manager maintains; the leader develops.
– The manager focuses on systems and structure; the leader focuses on people.
– The manager relies on control; the leader inspires trust.
– The manager has a short-range view; the leader has a long-range perspective.
– The manager asks how and when; the leader asks what and why.
– The manager has his or her eye always on the bottom line; the leader’s eye is on the horizon.
– The manager imitates; the leader originates.
– The manager accepts the status quo; the leader challenges it.
– The manager is the classic good soldier; the leader is his or her own person.
– The manager does things right; the leader does the right thing.

I don't necessarily agree with every point above. For example, I don't agree when he says that a manager has a short-range view and a leader a long-range perspective. A manager can be strategic as well as manage short term deadlines.

I often say that managers must lead their organisations to achieve the set objectives. A manager can also be a leader, and vice-verse.

Project management tools for Agile projects

This is a post by guest blogger Steward Copper

A few days ago I was attending the IT Project Management Conference and participated in a survey. All the attendants were asked one question: "What project management tool or solution do you use for the Agile projects?" Among the Top-10 Agile tools there were the ones I'd used to manage, plan and track my projects and processes - MS Excel, Pivotal Tracker, Comindware and VersionOne. So, let me share my thoughts and experience of using them for task management, sprint and iteration planning, daily meetings, burn-downcharts creation, project tracking and other Agile techniques.

MS Excel

The tool is a standard part of the MS Office package. The main general advantage of choosing it for your next project is that almost everybody is familiar with it and you don't need to spend time for the team training. It's used by many Agile PMs because it:

 - allows to create a product backlog while listing user stories, placing estimates and deadlines;

 - allows to plan iterations or sprints (it's good to create a template on a specific sheet);

 - allows to group tasks into sprints using a using a standard group tool;

 - allows to add any kind of comments for the tasks, stories and other entities using a standard commenting tool;

- allows to support daily stand-ups while filling a sprint progress data;

- provides very high level of flexibility while drawing graphs including burn-down chart, creating custom reports including digital dashboards and so on.

Excel helps many of us to manage projects but it's not so good for remote teams and big projects. Some managers don't use Excel because it doesn't provide the set of predefined processes.

Pivotal Tracker

The tool was created as a SaaS issue tracking system and evolved into a complex solution to support all the main processes of an Agile project. It's chosen thanks to the following:

- it's developed especially for Agile projects and uses Iterative Management Workflow approach;

- it allows to create iterations or sprints including tasks (tickets) of different priority;



- user-friendly dashboard provides one view of theentire project allowing to see the real time information for all the project stakeholders;

- it's good for the team collaboration including daily stand-up meetings and remote teams management;

- it automatically creates charts, including release burn-down, iteration burn-up, story type breakdown, and historical velocity;

- it is available for the iOS platform (iPhone andiPad) and so on.

The tool is recommended by many Agile evangelists including those using Kanban, Scrum Lean and XP. But it's not the only solution on the market. New solutions appear with new additional features. Comindware is a good example.

Comindware

The tool is little bit more than just an Agile software. It combines collaborative task management with workflow automation capabilities. The main feature that allows Comindware to compete successfully with the other solutions is its 100% flexibility (or better to say agility). Project or process manager may create a specific workflow or edit predefined processes even in the middle of a project. The other interesting features used to manage Agile projects are:

- creating and assigning tasks (auto-generated tasks from workflows andtraditional task lists created manually), setting up their priorities;

- project team collaboration which is very essential while managing remote and virtual teams;

- real time status reports including priority, deadline and other reports that are very helpful during daily stand-ups;

- customizable visual dashboard that is perfectly used not only to create all possible types of charts and graphs but also to provide visual information to project stakeholders;

- portfolio management feature allowing to manage multiple projects and generate aggregated reports;

- easy integration (if necessary) with the other tools like SalesForceCRM and MS Outlook.

The Comindware solution may be used as a cloud-basedservice (more cost-effective option) and as a on-premise software (to get the maximum control). It's really a good solution with plenty of different useful features that go far over just an Agile project management. But for those who feel that it's too flexible and has too many features there is a VersionOne.

VersionOne

The tool is better known as a Scrum project management solution, but thanks to a big amount of functionalities it can be used for all Agile methodologies. I've listed the main reasons why managers prefer VersionOne nowadays:

- it allows to manage multiple projects and iterations at the same time;

- it allows to plan sprints and to manage requirements, user stories and epics using very user-friendly interface (I've even heard that some experts named VersionOne as the tool of the best usability);

- it may be used for the team collaboration (sharing files, ideas and messages);

- it allows to create visual burn-down charts, so as storyboards, trackboards,testboards;

- it may be connected with other tools used in software development projects like CruiseControl, Jira,
Bugzilla, TeamCity and etc. allowing better flexibility;

- it provides almost everything for a good reporting andanalysis because there are more than 50 agile metrics and reports, so as a custom analytics platform.

Instead of a conclusion:

Today we have so many software tools that even a very professional project manager may face a problem of choice. So, while choosing the best solution for your next Agile project don't forget the golden rule: a tool is nothing more than an instrument that has to serve the goals of your project and to help you and the team to be effective. As for me for my current projects I use MS Excel (simple on-site projects and to-do lists) and Comindware (middle-size and big projects, processes, managing remote teams).

Author
Hi, my name’s Steward Copper and I am the owner of Project Management Insights. While working as a project coordinator and BA, I have tried almost all possible PM tools, BA instruments, collaboration programs, including tracker and hr system solutions. I also write for different blogs sharing my knowledge and observations.

How to develop effective professional relationships

We all know how important it is to build effective professional relationships. Relationship management is a very important skill for every professional that wants to get ahead. This article will focus on how effective relationship management helps the CIO to get ahead.

The top IT job is very complex and demanding, effective relationship management enables the CIO to build rapport with his/her peers and will most certainly make the job of managing IT much easier.

Before proceeding, it is important to define what the term "effective professional relationships" means. The CIO should spend most of his time interacting with his peers in order to understand the organization's needs and provide adequate IT solutions. Furthermore, the CIO needs to be able to convince other members of the organization that a particular IT project will deliver positive outcomes to the business. Effective relationship management are the ones that enable the CIO to effectively interactive with every member of the organization in order to enable him to achieve his objectives.

The following points provide useful insights on how to develop effective professional relationships.

Know your company and the people you work with

 

This should go without saying, but it is really important that CIOs know their business. What I find interesting about IT management is how broad the role really is. As an example, a Supply Chain Manager is required to know all about supply chain.He is not meant to know anything about how to operate the email server. However, the IT Manager, the one who wants to do a good job, is required to know not only about IT but also about every other area of the business. Obviously the IT manager is not required to know everything  in detail, however he needs to know enough about every area of the business in order to have systems in place that support the various business processes. I find this quite interesting and is what makes the job so interesting.

As the head of IT you need to know the vision and mission of the organization, the products it sells or the services it provides, how it makes money, how it spends money, the competition, the industry, etc... The list is quite long and varies depending on the nature of the organization. The point here is to know everything you can about your business in order to enable you to be a valuable member of the board and/or the senior management team.

I have heard many IT managers complaining that they don't get a chair in the company board of directors and/or don't have opportunities to participate in strategic meetings. Maybe the reason that happens is because the CEO, CFO and other members of the organization perceive the CIO as only a technical resource. That limits the effectiveness of IT. The CIO needs to not only know the organization but he also needs to show to the other members of the senior management team that he can positively contribute to non-technical discussions.

Build a good track record

 

This really means do what you said you would do. Honor your commitments.  Your peers should be able to trust you. Ensure to deliver on every deadline. If you know you will not be able to get something done speak to everyone involved as soon as you can. People will trust you because you always do what you say.

Having a good track record will help you to build a good reputation and nothing is more important than a good reputation.

Quote your peers whenever you can

 

This is quite powerful. When giving credit to someone, you are giving someone else a good reputation. This is especially powerful if the person is present in the conversation. They will always be thankful to you and are likely to return the favor.

Think about it the other way. If you take someone's idea and quote it as your own, you are actually robbing them a reputation they deserve. Worse still, remember that people talk in organizations and that particular idea you are taking ownership may have already been discussed so others might know whose idea that is. People may pick up on it and it can actually destroy your reputation.

Quoting your peers, positively that is, will go a long way in building rapport with them.

Discuss your concerns directly with the people involved

 

It is very important to raise your concerns with the people that are involved in it. Say for example that you have a concern about a particular business practice related to complaint handling. You will look really bad if you approach your boss, especially if he/she is the CEO. The best option is to organize a meeting and raise it directly with the relevant people and not only raise issues but also propose solutions.

However, it is easy for IT managers to be perceived as nosy and wanting to solve someone's problem, or even worse. You need to be careful about the reasons you are raising the issue and try to make it relevant to IT as well. It is not a good idea to say that complaints are not been handled effectively unless your issue relates to IT and you can provide some sort of solution.

Be professional, speak calmly, accurately and concisely

 

In order to build good, professional relationships, it is important to be professional and consistent at all times. Your emotions should not dictate how you react to an issue. There is nothing worse than knowing that you have to deal with someone but you never know how that person will react because he/she has a reputation of being unstable.

Ensure to always be professional, polite and accurate. Most importantly, do not lie. Others can probably see through you so don't even think about it.

Ask insightful questions and encourage a response

 

There is nothing worse than being in a meeting with someone who keeps on asking irrelevant questions and is always interrupting others before they finish talking. It is annoying and a waste of everyone's time. Make sure you are not the one making those mistakes.

It is impossible to plan for every interaction with your peers, however when attending meetings, ensure that you know thoroughly the topic at hand and only ask meaningful and insighful questions. Don't waste anyone's time.

Listen to what people are saying

 

Have you ever been in a conversation and got the feeling that the other person was just not listening? This is even worse if it happens at work. When talking to someone or participating in a meeting, make the other people you are talking to feel that they are the most important people in the world. Give them your full attention, be interested in what they are saying, value what they are saying even if you think they are wrong.

It is only when you really listen to people that you are able to ask meaningful questions and have positive interactions.

Many other points could be raised on this topic, however the list above provides a good summary on ho to go about building effective professional relationships.

The Good Product Manager vs. The Bad Product Manager

Today I came across the Good Product Manager/Bad Product Manager courtesy lecture at the Stanford university by Ben Horowitz, I believe this post is a classic for product management.

I have summarized Ben's points as follows:

 

 Bad Product Manager

• Always makes lots of excuses.

• A bad product manager is not the product's CEO.

• Lacks in communication skills. Bad product managers don't communicate well with the engineering team and tend to blame them when things go wrong due to bad communication.

• Puts out fires all day and complains that is swamped by questions and interruptions.

• When things go wrong they quickly point out that they predicted they would fail and the "powers of be" didn't do anything about it.

• Bad product managers focus the team on the feature that the competition is building.

• Bad product managers get confused on how to position their products on the market and how to leverage it.

• Bad product managers don't know how to work with the press, they don't manage the press.

• Bad product managers always want to be told what to do.

• Bad product managers don't produce status reports on time and are not disciplined.
  
• Bad product managers don't take responsibility and tend to blame others.

Good Product Manager

• Knows the product, the market and the competition really well.

• Is the CEO of the product.

• Takes responsibility for all aspects off the product.

• Manages himself based on the product's performance on the market.

• Takes responsibility for devising and executing a winning plan.

• Good product managers manage the product team and not every detail of every aspect of everyone's work. He/she knows how to delegate and manage the team effectively.

• Good product managers are focused on strategic decisions, ensuring that the product is flexible and adaptable to a changing business environment.
  
• Good product managers create lots of collateral to support the day-to-day operations of the team. He/she is not swamped by questions about the product and ensure that they are not the only ones that can answer questions about the product.

• Following from the previous point, good product managers equip their team to handle the day to day activities allowing them to focus on strategic topics such as market positioning, timing, etc...

• Good product managers focus the team on revenue and customers,

• Good product managers focus on delivering value to the market place and not on just matching the competition.

• Good product managers think about the story they want published on the press and they manage the press, not the other way around.

• Good product managers are disciplined and produce status reports on time.

The courtesy lecture I read today can be found here.

One skill that is vital for good product management is the ability to build good professional relationships. In this article I explain the importance of building professional relationships in the context of IT Management. The same principles apply to product management, in fact, these principles apply to any profession these days.

Whilst the following articles are not written in the context of product management, the principles apply. As a matter of fact, I believe that many product managers lack good planning and management skills which hinder their ability to really excel in their product management career.

•  Management theory and IT Management Part 1 - Planning
• Management theory and IT Management Part 2 - Organizing
• The effective IT manager, the importance of relationship management

 In essence a good product manager is the CEO of the product, knows how to manage the team, the press and ensures to deliver value to the market place.

What are your experiences in product management, what makes a good product manager in your view?