Meeting About a Meeting

When I was a co-op student I heard about a manager who held a meeting to prepare for a meeting.  It was an infinite source of amusement for myself, the other co-ops working at the same oil company, and my friends.  A meeting about a meeting seemed to be the penultimate bureaucratic time-waster.  Hah!  We would all be much smater and more efficient when we became managers.

Today, I do the same thing.  I cringe every time I do it, but sometimes it's just necessary.  Getting the right folks on board, getting commitment before meeetings, and getting agreement on key issues before a public discussion is crucial to the success of managing complex problems.  You don't want to argue publicly in front of the wrong folks.  You don't want the meeting to become an opportunity for grandstanding.  You do want to get something done with the minimum fuss and bother.

To ease your agenda into play, management becomes an act of diplomacy.  Educate folks on the issues before asking them to make a decision.  Socialize new concepts among the affected parties before asking for commitment of resources.  We need to work with colleauges prior to a decision-making event like a meeting to ensure there is common understanding and shared enthusiasm.  Spending time managing the politics of an issue is just as important as managing the content of the issue.

So if you do it right, sometimes a meeting about a meeting can be penultimate anti-bureaucratic time-saver.

~

Delegate, Don't Abdicate

I get concerned when folks arbitrarily say micro-management is a bad thing.  I agree that on a regular basis micro-management is a sign of a bad manager.  But on the other hand, a manager who doesn't know when to micro-manage is a probably a worse manager.

A manager is supposed to set the direction, clear the path, and then let staff get the job done.  Sounds great in theory.  Sometimes it's called empowerment, other times it's called delegation.  But delegation without control is abdication.

A manager who delegates and walks away is rolling the dice.  Sometimes the empowered team does a great job, other times they need a light to guide them.  Sometimes even the best and the brightest teams need ongoing managerial support.  Without a feedback and monitoring process they can easily lose their way.

There is nothing wrong with a manager getting involved in the details of the work when needed by the team.  The problem starts when the team needs help and doesn't know it.  A manager who sees the problem and blindly dives in to solve it will be accused of micro-managing, even if she or he is doing the right thing.  Staff will resent the manager's involvement and see it as interference.

The best managers set expectations early and clearly and monitor progress.  Before embarking on the journey, the manager sets thresholds and measures.  If the team veers off the planned path, predetermined triggers agreed to by the team engage the manager in the details.  That's not micro-managing - that's just common sense and good practice.

Good managers delegate work, but they don't abdicate accountability for getting the job done.

~

The Product Owner Problem

“We’re really struggling with the Product Owner concept, and many of our Scrum teams just don’t feel very productive.” they told us. “We’d like you to take a look at this and make some recommendations.” The company had several vertical markets, with a Scrum team of about ten people assigned to each market. Each market had a Product Manager, a traditional role found in most product companies. The company was clear about the role of a Product Manager; after all, there are university courses and professional organizations for this role. The Product Managers had a customer-facing job that included business responsibility for determining product direction and capability.

However, there was serious confusion about the Scrum role of Product Owner and its fit with the classic role of Product Manager. In addition to business responsibility, the Scrum Product Owner has the team-facing responsibility of managing the detailed product requirements.[1] In this company, the Product Managers found it impossible to handle both the customer-facing and team-facing jobs at the same time. So most teams had added an additional person to assist the Product Manager by preparing stories for the team, and called this person the Product Owner. The job of these Product Owners resembled the classic role of business analyst or, in some cases, user interaction designer.

Unfortunately, these Product Owners had little technical background in analysis or design, and yet they were expected to prepare detailed stories for the development team. Critical tradeoffs between business and technical issues often fell to these Scrum Product Owners, yet they had neither the first hand customer knowledge nor the in-depth technical knowledge to make such decisions wisely. They had become a choke point in the information flow between the Product Manager and the development team.

We asked the obvious question: How are things organized in the markets where things seem to be working well? It turns out that in the two highly successful vertical markets, there was no Product Owner preparing and prioritizing stories for the development team. Instead, the Product Manager had regular high level conversations with the development team about the general capabilities that would be desirable over the next two or three months. They discussed the feasibility of adding features and the results that could be expected. A real time application was created to show live web analytics of several key metrics that the Product Manager correlated to increased revenue. Then the team developed the capabilities most likely to drive the metrics in the right direction, observed the results, and modified their development plans accordingly.

This is a pattern we have seen frequently: Product Managers who lack the time, training, or temperament to handle both the customer-facing and the team-facing responsibilities of software development have two options. They can appoint Scrum Product Owners for each development team, or they can provide high-level guidance to a development team capable of designing the product and setting its own priorities. We observe that the second option generally works better, because an intermediary Product Owner brings a single perspective and limited time to the complex job of designing a product.

In 1988, Tom Gilb wrote the book Principles of Software Engineering Management, which is now in its 20th printing. One of the earliest advocates of evolutionary development, he has recently reiterated the elements of good software engineering in an article in Agile Record[2], from which I quote liberally:

Principle 1. Control projects by quantified critical-few, results.
1 Page total! (not stories, functions, features, use cases, objects, ..)

Principle 2. Make sure those results are business results, not technical.
Align your project with your financial sponsor’s interests!

Principle 3. Give developers freedom, to find out how to deliver those results.
The worst scenario I can imagine is when we allow real customers, users, and our own salespeople to dictate ‘functions and features’ to the developers, carefully disguised as ‘customer requirements’. Maybe conveyed by our Product Owners. If you go slightly below the surface, of these false ‘requirements’ (‘means’, not ‘ends’), you will immediately find that they are not really requirements. They are really bad amateur design, for the ‘real’ requirements – implied but not well defined.

Principle 4. Estimate the impacts of your designs, on your quantified goals.
….We have to design and architect with regard to many stakeholders, many quality and performance objectives, many constraints, many conflicting priorities. We have to do so in an ongoing evolutionary sea of changes with regard to all requirements, all stakeholders, all priorities, and all potential architectures…. a designer [should be able] to estimate the many impacts of a suggested design on our requirements.

Principle 5. Select designs with the best value impacts for their costs, do them first.
Assuming we find the assertion above, that we should estimate and measure the potential, and real, impacts of designs and architecture on our requirements, to be common sense. Then I would like to argue that our basic method of deciding ‘which designs to adopt’, should be based on which ones have the best value for money.

Principle 6. Decompose the workflow, into weekly (or 2% of budget) time boxes.
….I would argue that we need to do more than chunk by ‘product owner prioritized requirements’. We need to chunk the value flow itself – not just by story/function/use cases. This value chunking is similar to the previous principle of prioritizing the designs of best value/cost.

Principle 7. Change designs, based on quantified value and cost experience of implementation.

Principle 8. Change requirements, based in quantified value and cost experience, new inputs.

Principle 9. Involve the stakeholders, every week, in setting quantified value goals.
….In real projects, of moderate size, there are 20 to 40 interesting stakeholder roles worth considering…. But it can never be a simple matter of analyzing all stakeholders and their needs, and priorities of those needs up front. The fact of actual value delivery on a continuous basis will change needs and priorities. The external environment of stakeholders (politics, competitors, science, economics) will constantly change their priorities, and indeed even change the fact of who the stakeholders are. So we need to keep some kind of line open to the real world, on a continuous basis. We need to try to sense new prioritized requirements as they emerge, in front of earlier winners. It is not enough to think of requirements as simple functions and use cases. The most critical and pervasive requirements are overall system quality requirements, and it is the numeric levels of the ‘ilities’ that are critical to adjust, so they are in balance with all other considerations.

Principle 10. Involve the stakeholders, every week, in actually using value increments.
….I believe that should be the aim of each increment. Not ‘delivering working code to customers’. This means you need to recognize exactly which stakeholder type is projected to receive exactly which value improvement, and plan to have them, or a useful subset of them, on hand to get the increment, and evaluate the value delivered.

The Scrum Product Owner might be a role, but it should not be a job title. Product Owners wear many hats: Product Manager, Systems Engineer, User Interaction Designer, Software Architect, Business Analyst, Quality Assurance Expert, even Technical Writer. We would do well to use these well-known job titles, rather than invent a new, ambiguous title that tends to create a choke point and often removes from the development team its most important role – that of product design.

Discovery of the right thing to build is the most important step in creating a good product. Get that wrong and you have achieved 100% waste. Delegating decisions about what to build to a single Product Owner is outsourcing the most important work of the development team to a person who is unlikely to have the skills or knowledge to make really good decisions. The flaw in many Product Owner implementations is the idea that the Product Owner prepares detailed stories for the team to implement. This does not allow team members to be partners and collaborators in designing the product.

The entire team needs to be part of the design decision process. Team members should have the level of knowledge of the problems and opportunities being addressed necessary for them to contribute their unique perspective to the product design. Only when decisions cannot be made by the development team would they be resolved by a product leader. The main team-facing responsibility of the product leader is to ensure the people doing the detailed design have a clear understanding of the overall product direction.

The concept of single focus of accountability is at the center of this issue. Too often, accountability is implemented as a prioritized list of product details (stories) rather than as communication of intended results (business relevant metrics). As a result, the expertise, creative input, and passion of team members is sacrificed to the false goal of a single point of responsibility.
___________________
Footnotes:
[1] “The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization.” “The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases.” From Scrum: Developed and sustained by Ken Schwaber and Jeff Sutherland; http://www.scrum.org/scrumguides/.

[2] “Value-Driven Development Principles and Values – Agility is the Tool, not the Master.” Agile Record, Issue 3, July 2010, pp 18-25. Available at www.agilerecord.com. Used with permission.

Screen Beans Art, © A Bit Better Corporation

A Vast Array of Interwoven Matrices

To get work done in a planned fashion we create formal organization structures.  From bureaucracies to ad-hocracies, we develop structures to address the specific unique needs of the environment we serve.  The environment dictates competitive pressures, quality expectations, capacity needs, investment returns, and agility demands.

With apologies to organizational theorists, such a variety of demands renders any single organization structure incapable of meeting all needs.  In other words, one size fits none.

So we build a basic formal structure that meets the core, high priority needs of the environment we are trying to serve.  If you look carefully at any industry, you will find most of the players use fairly similar formal organizations.  Because of pragmatic external pressures, if you examine any two large companies in the insurance industry, they will likely be divided into group and individual insurance divisions.  Hardly rocket science and hardly a competitive advantage.  Simply a realistic necessity.

To meet unique demands and to be competitive, organizations must relentlessly find ways to distinguish themselves.  We create cross-functional links that span the formal structure creating short-cuts.  We design dynamic teams using subject matter expertise from across different knowledge realms to develop unique value-building entities.  Hopefully these combinations create efficiencies and innovations that cannot be copied by other organizations in the same market space.

These cross-functional webs superimpose a wide variety of structures over the traditional organization chart.  Now, add in the informal organizations that humans invariably create.  Regardless of the formal structure or any cross-functional team, humans seem to find ingenious ways of connecting and re-combining into completely unexpected groups as a result of interpersonal relationships and informal hierarchies of expertise and respect.

These informal groups add yet another layer onto the organization.  Suddenly the nice neat organization chart becomes a "vast array of interwoven matrices."  (Thanks to Alan Harrison for that quote).  Is this complexity such a bad thing?  Certainly it doesn't fit into an easy to categorize organization architecture.  But the trade-off is a dynamic living organism that can respond to external pressures in an infinite number of ways.  It may seem confusing, but I wouldn't want it any other way.

~

The Snowflake Theory of Management

I heard myself saying every business relationship is a like snowflake yesterday.  I thought it sounded a little corny at the time and I wondered if I could just rewind time and take it back.

In retrospect, I'm glad I couldn't.  Every relationship is different and every relationship is ephemeral.  Our organization supports over a hundred different departments and thousands of individuals across the institution.  It would be impossible to create a separate process for every relationship.

So our processes become frameworks for enabling individuality to thrive.  The framework sets the boundaries around how far we can go, how much we're willing to spend, and who we can support.  But within those guidelines, the individual needs the freedom to do their job.

A good example is our project management process.  It is quite rigorous about specific activities.  We demand a project charter document to explain the business case justifying the project.  A project plan is expected to define how the project is to be executed.  Regular status reports are produced to track progress to plan.  The project is wrapped up through a project closure report.  That's all.

The process doesn't get any more prescriptive.  There is lots of room to maneuver within the framework.  Project managers are free to apply their personal creativity to get the job done within a small set of very specific checkpoints.  

This approach gives the management team the appropriate level of control over the process without stifling the individuality of the project managers.  The freedom to make a broad range of decisions within a small set of clearly defined rules allows control that supports the flexibility required to adapt to the unique set of circumstances inherent in every project.

The same is true of any process we build.  Because each relationship between the organization and its clients is independent, we need to build processes that simultaneously enable flexibility and control.  The trick is to ensure the appropriate degree of flexibility and while ensuring we can still control the quality and efficiency of our process.

Hmmm ... it looks like it's snowing outside ...

~

My Job

My job is simple.  I go to meetings and drink coffee.  Lots of meetings and probably too much coffee.  The day becomes an endless stream of conversations woven into a fibre.  A fibre used to bind ideas and people into actions.

Sometimes the conversations are quick snippets in a hallway to touch base.  Other times it's the full two hour marathon group meeting with a sea of brilliant minds contributing to the idea pot.  There are happy congratulatory chats and darkly serious budget banter.  The detailed projected benefits email, the text message from the coffee line-up, and the surreptitious tweet during a meeting are all part of the fibre.

Lots of variety - different people different topics different issues.  Finding consistency in the constant exchange is hard.  A manager can't just treat each chat as a random separate event.  Even if you considered each conversation an independent transaction, the volume makes adding value in a disciplined way impossible.  You could try structuring your day around key projects, but there are too many other folks outside your sphere of influence to make it feasible.

But what if you developed a set of basic principles or core competencies?  You could apply some rules like "treat everyone with respect" to each conversation.  That's a good start, but not enough. Principles don't establish schedules.  In a day of constant conversational transactions, how do figure out what to do next?  How do you set guidance for your staff?

Start with principles to create consistency and then set your priorities.  Go through the day with few precedence rules.  The fewer priorities, the better.  I go through the day with just one priority: how is our organization going to be the best?  So each conversation goes through that single filter.  How can each transaction help make us the best?

My priority is to move my agenda forward.  Sounds selfish?  It isn't because all our clients benefit from us being the best.

Now ... its time for another coffee.

~

Time

There are many different criteria for assessing the various types of managers in an organization. An interesting challenge is how you consistently compare different types of managers in the same organization. In other words, is there one criteria that can be used to assess everyone? The question is important because the answer affects how we view organization structure.

For example, what makes a vice president different from a director, or what makes a director different from a manager? Is it because one level is more skilled than another? Skill assessment can be subjective, thus making it difficult to create consistency. Moreover, different levels require incomparable skills. For example, customer responsiveness skills are required for a call center representative; personnel management skills are needed for the call center manager.

Could we assess management types by determining whether one level is more politically savvy than the other? Does the vice president need to be a better diplomat than the sales manager? Yes, but does the sales manager need to have better selling skills than the VP? Neither of these skills provide a consistent way of assessing talent across all layers of management.

The problem lies in the idea that management has layers. Layers imply a two dimensional view of organizations: breadth and depth. That hardly represents the real world of human interactions. Any hierarchical view is static and successful organizations never stand still. Layers don't get work done because they don't capture the inexorable forward movement needed to sustain the life of the organization.

Looking forward to the future creates a common dimension. Every management role requires a time perspective. Each type of manager is differentiated by how far forward they need to think to get their job done. Time is the only dimension of management shared by everyone.

Think about a software company that produces tax reporting tools. A programmer in that organization is trying to complete a module by Monday. The project leader is trying to complete phase one of the project by month-end. The product manager is trying to get the annual release to customers before tax season starts at the end of the quarter. The director is planning the upgrades for next year's version of the product, and the vice president is planning a new business to spin off when the government revamps taxation legislation in three years.

Each job in this example is very different. Specific skills are quite different in each role, but each member in the organization is consistently differentiated by their time perspective. The layers may exist, but they are irrelevant to the dimension of time.

Time transcends layers. To understand and compare various managers in an organization, think about management differences based on their time-frame accountability. Each management role looks at the same company from differing time lines. Ultimately, managers' ability can only be consistently assessed by the time horizon in which they plan and execute their work.

~

Appraising Performance Appraisals

I've always been a big believer in giving positive feedback and encouraging enthusiasm.  Performance appraisals can be a wonderful motivational opportunity.  The challenge is to provide adequate criticism while continuing to nurture and improve staff.

I learned a little bit more about appraisals after receiving an evaluation of a presentation I gave recently.  The evaluation results were generally good.  I was feeling satisfied with the statistics and most of the written comments.  There were a couple of some solid criticisms about things that I knew did not go right.  But there was also one scathing comment about something I did not expect.

Clearly one person disagreed with one of my points in a big way.  There were over 100 folks in the room and I only really upset one person. Should I ignore it and focus on the positive?  Statistically speaking I should not worry about it.  However, the individual took and effort time to write their comment - obviously the issue was important to them and they felt obliged to make their point to me.

I kept thinking about the comment, so I pulled out my speaking notes and reviewed the point again.  I may have been right, but I also may have stated my case too strongly.  If I give the same talk in the future, I am going to re-write that particular point.  Although the powerfully worded feedback was painful, it was probably the most useful feedback I received.

From a management perspective, this experience provides an interesting lesson about performance feedback.  The conference comment certainly surprised me and it made me think more deeply about feedback in general.  When we do staff performance appraisals are doing anyone any favors by watering down criticisms?  Are staff really going to improve if you are not specific about issues?  On the other hand, such feedback can be highly de-motivating.  How do you resolve this inherent conflict?

The answer lies in the surprise.  For me, the negative presentation feedback came as a surprise.  I had no early warning that it was coming.  The same is true of staff performance appraisals.  If a formal appraisal is written once a year, none of the issues should be a surprise.  Managers must provide feedback to staff at every opportunity and cannot wait for the once-a-year appraisal meeting.

As managers we are obliged to inform, coach, and guide staff members throughout the year about any problems.  By the time the performance appraisal meeting arrives, the issue should be a familiar one with a history of suggestions and (hopefully) improvements.  Instead of crushing someone's enthusiasm in a surprise one-time event, you need to gently guide it in the right direction over time.

Ultimately, successful performance appraisals are not just about the employee's skills.  Successful appraisals reflect the manager's skills as a mentor.

~

Management = Learning + Teaching

I always look up to my boss or quickly find somewhere else to work.  You don't grow if you don't learn and I've always found my boss to be a wonderful learning resource.  That perspective is simply common sense.  Convention wisdom says you learn from someone who has more experience and more breadth of responsibility.

In the same vein, I want my direct reports to learn from me.  They can learn by example (sometimes what to do ... sometimes what not to do), or by mentoring, or by coaching.  This flow of knowledge and skill in theory helps the organization to grow its intellectual capital.  Intellectual capital is an asset whose real value typically exceeds any physical asset in knowledge-based organization.

But the real joy is when the knowledge flow goes both ways.  I have a leadership team where I think I learn more from them than I learn from anyone else. Management is about teaching to staff and learning from staff.  The traditional, conventional view of managers having all the experience and knowledge just doesn't make sense.

Most managerial skills are ephemeral.  Our work environment changes continuously, whether we are aware of it or not.  You have to learn from every possible source.  Why not your own staff?

~

Management Secrets of Napoleon

The collective business wisdom over the past few decades attempts to distinguish between leadership and management.  We seem to be at a point where leadership is considered "good" and management is "bad."  Culturally, we are trying to inspire folks to be great leaders at the expense of classifying management as a discipline of bureaucratic administration.

I think leadership is important.  However, would you prefer great leadership as a substitute for strong managerial skills?  Think about Napoleon.  Historically he is viewed as a great leader.  But the most substantial element of his success was his logistics ability.  He focused on the details of supply and coordination to get his army to the right place on time and on budget.  Remember, he was the guy who said an army marches on its stomach.

For Napoleon, leadership on the battlefield was a key skill.  He did win almost every battle he fought for many years.  But he viewed leadership as a tactical skill to be deployed in specific circumstances such as battle.  His strategic skill needed to win wars was his administrative ability.

I worked at an insurance company several years ago that called everyone in management "leaders."  We believed that nomenclature change was a great innovation reflecting new age business thinking.  It acted as a cultural change to galvanize corporate thinking in a new direction.  The company went from the verge of bankruptcy to becoming the most profitable general insurance carrier in Canada in five years.

We could not have transformed the company without inspired leadership.  But beneath the layer of leadership was an extraordinary focus on rigorous process improvement, metrics, and organizational re-design.  These changes were all driven by fundamental administrative management disciplines.  Leadership was part of the solution, but comprehensive management skill was the complete solution.

For organizational managers, leadership is an absolutely key skill.  But it is not the only one.  Leadership is simply one of many tools used by the truly skilled manager.

~

Data is Free

I'm probably not the first person to say this, but electronic data has no boundaries.  Whether you agree or disagree with what happened with WikiLeaks, the incident illustrates the difficulty in preventing the electronic flow of any information.  I wonder how long it will take a similar site to be established in a jurisdiction where the owner cannot be prosecuted.

It was a similar issue with LimeWire.  It took a very long time to shut it down.  During the years it operated, the volume of illegal copies of intellectual property made was staggering.  Despite the rampant viruses on LimeWire, it was still cheaper than buying it.  I don't advocate piracy or theft, but the forces that closed LimeWire cannot reach every potential file sharing host on the internet.

Like it or not, there are no sustainable boundaries to data.  Just like water flowing along the path of least resistance, data will eventually flow to whoever wants it.  So how do organizations get value from data they produce if they accept the inevitability that proprietary data is impossible to corral?

Maybe we should borrow a page from the open source software play book.  When software is free, the economic model is based on the value derived from understanding how the software works and how it can be applied for functional use.  Maybe we simply accept the reality that any data we create is of no standalone economic value, no matter how much effort is required to derive or collect it. Perhaps the real value of our data is in the intellectual capital we apply to interpreting the data for pragmatic applications.

Once we accept the inevitability of the economic forces at work, we can look for new models to build a new value chain.

~

Research Entrepreneurs

Smart people solving complex problems.  That`s how we typically view University researchers.  But that description does not really do them justice.  I would suggest that there is lot more to the work they do than simply research.

I watch a number of researchers at our institution manage incredibly challenging research projects.  The complex problems they solve are not just related to the research issues.  For example, they have to raise money to fund their work, much like a business entrepreneur raises venture capital.  The process of acquiring the funding requires diplomacy and a solid rationale for why they need the money.  Ultimately, they have to navigate a complex labyrinth of funding agencies to source the capital.

Once they get their funding they have to hire staff, develop infrastructure, and create functional processes to operate the research.  Just like managers of any start-up company, they have to manage their research organization.  Because their work is highly innovative, they must lead an entity with a high risk profile - another example of leadership talent.

On top of all this entrepreneurial skill, they perform leading edge research.  So researchers are not just smart people solving complex problems.  They are also smart entrepreneurs managing complex organizations.

~

Shadows of the Future

I read about scenario planning as a grad student.  The idea sounded great.  It was started in the 1970's by Shell Oil to analyse multiple potential futures.  The result was a strategic plan with built-in flexibility to compensate for unpredictable risk.  According to all the literature, it was wildly successful for Shell.

What baffled me was that in my entire management career, nobody ever practiced it.  Moreover, I've never met anyone who had.  But today we tried a scenario planning exercise for research libraries.  A group of library and systems managers worked together to analyse four potential scenarios.  Each scenario was set 20 years in the future, and each represented wildly different final states.

Are we to become an institution whose research community was made up of global followers, research entrepreneurs, discipline driven specialists, or scrounging re-cyclists?  We divided into four teams and spent the morning analyzing how our institution might be driven into these possible situations.  I really looked forward to the debate that would ensue as each group presented its vision for the future and how we would get there.

I certainly didn't get what I expected.  Although the future worlds all looked different, there were similar forces at work in each scenario.  A shifting economy, changing demographics, and growing international competition, amongst several other changes, are shaping our next two decades.  We discovered the difference is not in what forces are pressuring us, but in how we react to those forces.  Each reaction is a decision.

Twenty years may seem like a long time.  But our scenario planning exercise made it clear that the choices we make today can have dramatic consequences.  The future casts a long shadow on the present.

~

The Sign of a Real Team

There are probably more books about leading and managing teams than there are teams in the world.  There are new theories daily about how to build a super team.  There are self-help books about how to be a great team player.  There even books about how to spell team.

I haven't seen too many good books about how to measure the quality of a team.  Do they win more awards?  Are they more productive?  Do they give each other more high fives?  Most of the measures seem contrived and derivative.

I think the best teams are the ones that surprise you.  Not because they're underdogs.  No, the best teams are the ones that get better even after you thought they were already really darn good.  We are facing budget cuts at our institution.   Never a pleasant process, but sometimes necessary.  Normally this activity brings out the worst in people.

In planning for these cuts, I asked my leadership team to come back with budget reduction suggestions for each of their own departments.  The surprise: they each did the best they could without regard for whether they were absorbing a disproportionate amount of the change.  Instead of being territorial or turf-protecting they worked together.  No one bickered and everyone supported each other despite the difficult nature of the process.

That's the sign of a real team.

~

Service Level Agony

I've always approached information systems Service Level Agreements (SLAs) with caution. In theory, if we provide great service that a customer loves, then why would we need a contract?  If we don't provide great service then we shouldn't provide that service.  Simple black and white choice, right?  Unfortunately, reality introduces some shades of gray.  What happens if customer expectations of great service are not aligned with our perception of great service?  Or, what happens, when staff change on both sides?  They bring new attitudes to the relationship.

The real value of a service level agreement forces both parties to come to consensus about what we both define as great service.  As people change over time, this definition remains constant because of the agreement. Attitudes may change but the contract ensures consistency.  It allows both sides to plan for the future with some certainty.

But what happens when motivations for entering into the agreement are skewed?  For example, getting consensus when one or both parties have ulterior motives can certainly be difficult.  Do you voluntarily sign a deal you don't believe in, for the sake of maintaining organizational harmony?  Or, what happens when you don't have the necessary resources to provide a mandatory service?  Finally, does the customer realize they have as many obligations in a well written SLA as you do?

I don't have good answers to any of these questions.  However, I do have one simple success measure.  The best service level agreements are the ones that are never used.  A good relationship transcends any contractual obligation.

~

The Dreaded Conversation

I checked my agenda this morning and saw a particularly sensitive meeting was scheduled.  With some trepidation I opened the agenda and saw the topic that had caused an infinite amount of grief in the organization. I was not looking forward to the conversation all day, so I resolved to go into the meeting without bias and without scar tissue.

By the time the meeting rolled around, I hadn't paid anymore attention to the issue.  The day had been too busy to allow time to think more about it.  I knew the topic was touchy and I suspect everyone else had the same queasy trepidation.  The meeting proceeding innocuously through the non-contentious topics.  Then we started talking about the big issue.

Everyone spoke in reasoned sequence.  No one allowed their biases in the room.  Preconceived notions were left at the door.  We looked each other in the eye and saw smart intelligent peers who deserved mutual respect.  Sensible conclusions were reached.  Nobody's feeling were hurt.

Wow - I wonder if we could bottle that magic and use it everywhere!

~

Appreciating Finance Committees(!)

Sometimes we don't really appreciate how well run an established organization can be until we work with a newly formed one.  For example, I sit on the Finance Committee of BCNet, and have been part of the committee for several years.  Over the years there have been several opportunities to improve the process and the reporting.  Although I would characterize these changes as minor tweaks to a well oiled machine, I always thought we had lots of room for improvement.

In contrast, the Canadian University Council of CIOs (CUCCIO) is a developing organization.  I'm on the Finance Committee for this organization too.  Although CUCCIO's finances are in good shape, I've discovered we have a long way to go before it is running anywhere nearly as smooth as BCNet.  The irony is that I don't think I ever really appreciated the BCNet committee until I started working on the CUCCIO finances.  Trying to model a new organization on an existing one certainly makes one appreciate the effort and complexity of the existing model.

I'm happy to be able to apply a number of lessons from BCNet to CUCCIO, and just as importantly, I'm humbled by the success of the BCNet process.  A double win!

~

Online Publishing

I published a short book last year using blurb.com.  The service was easy to use and helped a publishing neophyte like myself produce a relatively professional looking book.  To accompany the book I allowed a 15 page preview to be available.  There was a lot of interest in the book but nobody bought a copy.  So I figured I might as well put the whole book online for free.  That's when folks started buying copies!

I think it's interesting that completely free content lead to my first real sales, and now I've received my first royalty cheque.  Of course, after tax, that cheque is barely enough to buy myself & a friend a couple of coffees at Starbucks.  But I'm proud of it!

P.S. Here's the free link:  http://www.blurb.com/books/960910

~

Software Architecture in an Agile Development Environment using the Sashimi approach

Agile software development methodologies are  now widely accepted and utilised within the software development industry. There is however a lot of debate on how to perform effective and efficient software architecture within an agile environment.

In an non-Agile environment there is usually a lot of architectural discussions and decisions are made at the beginning of a project, practice which is discouraged in an agile environment.

So the question remains, how do you ensure that your architecture addresses the business requirements whilst keeping up with the agile practices. One of the 12 principles of the agile manifesto says that “the best architectures, requirements and designs emerge from self-organising teams”. I believe that this is the key to incorporating software architecture into the agile development approach, self-organising teams..

An Agile environment involves shared responsibility. The traditional role of the architect, as the one who defines the high-level solution, is diluted. The software architecture is performed by the entire team. This practice does not remove the need for a software architect, it just means that the architect contributes to the discussion with a broader and probably more experienced perspective, nevertheless all members of the team contribute towards the architecture of the software.The whole team participates in discussions and understands the consequences of design decision as they are made and, more importantly, these design decision are constantly evolved and evaluated.

Most of the architectural challenges are tackled by including them in iteration reviews, stand up meetings or any other development meeting. These discussions usually include lots of charts, diagrams, white boarding and other techniques. All of which helps to understand architectural challenges and to cement agreed solutions into everyone’s minds.



The Sashimi approach
There are several approaches to incorporate software architecture into an agile framework whilst keeping with the Agile principles of high customer involvement and feedback, continuous delivery of working software and attention to technical quality, amongst others.

One of these approaches is called Sashimi. In this approach the focus is on velocity. Instead of developing an architecture focused on tiers and layers you build the minimum amount of code that is necessary to connect all of the parts of the software and start building the actual functionality, which provides an early delivery of the software and enables the development team and customers to experience the software very early in the development process.

As the iterations progress the implementation is incrementally completed following the needs of the functional parts of the software, the business requirements. When performance and load tests are performed there is the opportunity to further tune the original design.

To be able to support this incremental approach to software architecture, the key is to implement well defined APIs over a “very” decoupled code, If the implementation details are moved outside the API, coupling with its consumers, then it becomes very difficult to refactor the architecture. Therefore it is key to have a well defined, decoupled API which will enable the Agile’s incremental approach. That is why API development is a key activity early in the lifecycle of the project.

Developers and architects that are not used to Agile development usually say that a detailed architecture design is necessary up-front because it is too hard and costly to change architectural building blocks once they are in place. The Sashimi approach deals with this argument and enables software architecture to be fully implemented into the Agile environment.

Technorati Tags: Agile development,software,software development,software architecture

Reference: The Architecture Journal #23 pg. 13.

Software Development Compilation

Welcome to the October 24, 2010 edition of software development compilation.

Software Development Management Articles
Software Architecture in an Agile environment using the Sashimi approach - Agile software development methodologies are  now widely accepted and utilised within the software development industry. There is however a lot of debate on how to perform effective and efficient software architecture within an agile environment.
Reader’s Sponsored Articles
Jennifer Saksa presents Software Buying Trends posted at NCH Software Blog.

Bernice Frankel presents Top 20 Mobile Education Apps: iPhone vs. Android posted at Masters Degrees, saying, "Mobile educational apps can give you an edge in and out of the classroom. Here are 20 great mobile education apps, 10 for the iPhone, and 10 for Android phones."

Lindsay Samuels presents The Bookworm?s Guide to the iPad: 100 Tips, Tools, and Tutorials posted at Library Science Degree, saying, "With any new piece of technology, confusion, turmoil, and frustration can quickly set in when spending so much money, along with learning something new. To help, the article has compiled a Bookworm’s Guide to the iPad: 100 tips, tools, and tutorials."

Chris Davis presents Robot Wars: 10 Recent Developments in Unmanned Warfare You Haven?t Heard About posted at Criminal Justice Degrees, saying, "When the war in Afghanistan kicked off, the U.S. military only had a handful of drones or unmanned weapons on the battlefield. Now it’s one of the military’s main concerns as they race to outdo the competition developing innovative robots that do the dirty work."

Carrie Oakley presents 40 iPad Apps That Librarians Love posted at Online Colleges, saying, "Librarians wear many hats at one time. Besides managing their space, they also organize events, reach out to the community and enhance the feel of the library, making it a timeless treasure that is making a major comeback."

Chirel Jack presents Freelance Jobs - Freelancer for hire posted at Hire consultant - Freelance jobs.

That concludes this edition. Submit your blog article to the next edition of software development compilation using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.

Share |

Technorati Tags: software,software development,software architecture,iPad,freelance jobs

del.icio.us Tags: software,software architecture,software development,iPad,freelance jobs

Software Development Compilation

Welcome to the October 17, 2010 edition of software development compilation.

Software Development Management Articles
Common Challenges of Managing Software Development Articles - There are many challenges in managing software development projects. The following list discusses a few topics that have been highlighted as common challenges of software development. The list is not exhaustive, it does however highlights some of the common challenges I have encountered, and addressed, over past 10 years working in software development.
The use of mashups in the enterprise - A mashup is a technique for building applications that combine data from multiple sources to create an integrated experience. Many mashups available today are hosted as websites on the internet, providing visual representations of publicly available data.
I have been observing a new trend in the software industry where applications are there to serve data and not the other way around. Data is at the centre of the universe  and not the application.
Take twitter for example, it is all about the data and not the application. There are so many twitter applications available to serve the data. Business Intelligence proves that when data is utilised effectively it can help organisations to achieve competitive advantage and consequently make more money. Super,markets organise the products on the shelves based on data served to them via business intelligence products such as reports from data warehouses and other. Another example is blogging which is all about what the author is saying, the data. There are many different blogging providers on the internet and many more applications that enable bloggers to create their blog posts and publish them to their website.
Reader’s Articles
Maureen Fitzsimmons presents Top 20 Most Influential Obesity Experts posted at MPH Degree, saying, "If you are looking for ways to improve your ability to write research papers, you are in luck. Technology makes it simple to get help with research papers, as these 20 iPad Apps demonstrate."
Heather Sanders presents 50 Interesting Engineers Worth a Follow on Twitter posted at Blogineering, saying, "If you are interested in learning a little bit more about engineering, you can follow these 50 interesting folks — including some engineering students — on Twitter."
Chris presents Chuck Norris Google Facts posted at Martial Development, saying, "Read these all-original "facts" about Chuck Norris' involvement with the world's most powerful search engine."
J Dumire presents Computer Memory Issues? Excessive Pop Ups? And Slow Operating Speed? posted at LightSpeedPC: No More Computer Lag.
J Dumire presents Don�t Buy a New Computer! You Probably Don�t Need One! posted at LightSpeedPC: No More Computer Lag.
That concludes this edition. Submit your blog article to the next edition of software development compilation using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.

Share |

Technorati tags: software development compilation, blog carnival.

Software Development Compilation

Welcome to the October 11, 2010 edition of software development compilation.

Software Development Management Articles
Common challenges of managing software development projects - There are many challenges in managing software development projects. The following list discusses a few topics that have been highlighted as common challenges of software development. The list is not exhaustive, it does however highlights some of the common challenges I have encountered, and addressed, over past 10 years working in software development.
The use of mashups in the enterprise - A mashup is a technique for building applications that combine data from multiple sources to create an integrated experience. Many mashups available today are hosted as websites on the internet, providing visual representations of publicly available data.
I have been observing a new trend in the software industry where applications are there to serve data and not the other way around. Data is at the centre of the universe  and not the application…
What makes a good software architect - I have recently read an interview with Ray Ozzie, Microsoft’s chief software architect where he spoke about his role as chief software architect and what makes a good software architect…
The effective IT manager – the importance of relationship building - Relationship building is an important skill that any IT manager should possess and develop in order to be an effective manager.
Reader’s Sponsored Articles
Bridget Nicholson presents 100 All-Time Greatest Popular Science Books posted at OEDb: Online Education Database.
Raphael Pereira presents Great resources to learn Haskell | Raphael Pereira posted at Raphael Pereira.
Jennifer Saksa presents Hello World! posted at NCH Software Blog, saying, "One software developer compares programing and trying to make user-friendly software to the "guest experience" in the restaurant industry and really taking the time to think about all of the little details and listen to customer feedback to help improve the entire process."
That concludes this edition. Submit your blog article to the next edition of software development compilation using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.

Share |

Technorati Tags: software development,management,software architecture,mashup

Common challenges of managing software development projects

There are many challenges in managing software development projects. The following list discusses a few topics that have been highlighted as common challenges of software development. The list is not exhaustive, it does however highlights some of the common challenges I have encountered, and addressed, over past 10 years working in software development.
Interpersonal skills – managing the stakeholders
Every IT project is also a business project, interaction with the business is a must. When declaring a project I always insist on having non-IT project owners and stakeholders. Even the most back-office related project needs to be reported to the business. I have recently participated in a project to provide new desktops to members of my organisation. A key part of the project was to involve members of the business to articulate requirements and to evaluate potential options for a desktop replacement.
Interpersonal skill is a very important skill that every IT manager needs to posses in order to be successful. Managing IT projects of any type (software development, security, etc…) will require a lot of interaction with other members of the business. Establishing and nurturing a healthy relationship between IT and other business units should be one of the priorities for any manager within the IT department.
Unfortunately many IT managers fail to address this topic and in doing so they minimise their chances of conducting successful projects.
Business requirements – the uncertainty factor
One of the main challenges in software development is gathering clear business requirements. When a project fails, many IT managers blame the lack of clear business requirements or the lack of communication from the business to notify changing requirements. I personally think that IT managers should take responsibility for their projects, stop blaming and start acting on it.
In my experience, business users may think they are communicating their requirements clearly but once the software is built they realise that they asked for the wrong functionality. This happens way to often. One of the possible strategies to address this issue is to use an agile methodology that builds the system in increments and gets the business users to review every increment built. This way if the requirement is not addressed as the users expect the issue can be dealt with before the system is live. This can save a lot of time and money.
Project management – real project management skills please
I have seen a few development projects being managed by individuals who do not posses the necessary project management skills to manage a project, let alone a software development project. Sometimes good software developers that evolve into management positions fall into the situation where they need to manage the projects, however, more often than not all that they do is create a good looking project plan that once approved is never revisited again.
Regardless of the background of the person managing software development projects, it is necessary that he/she possesses real project management skills and a track record of successful delivery of real life projects.
Resource management – managing IT and non-IT resources
One of the challenges in delivering software development projects is resource management (IT and non-IT resources). Non-IT staff need to be managed from different perspectives depending on their role in the project. Business managers that are not stakeholders in a project only care about high level updates, project stakeholders are interested in detailed updates and they are the ones providing the requirements for the project. .
It is very important that IT personnel develop professional relationships with members of the business in order to support business related communications. This relates to the first point mentioned above where I mention that IT managers need to have well developed interpersonal skills. For more information on relationship building please visit the article entitled The effective IT manager – the importance of relationship building.
In terms of IT resources, the project manager needs to ensure that the right IT resources with the necessary skills and experiences are allocated to the various projects. He needs to make sure that resources allocation is based on the requirements of each project. If your project requires a lot of complex  T-SQL, the manager needs to allocate a developer that has enough knowledge and experience in that area in order to maximise the chances of delivering a successful project.
Software architecture – maximising the use of IT assets
When working on software development projects, it is important to maximise the use of previous development investments by reutilising your IT assets. An IT asset may be a web service, a stored procedure or any architectural building block of an application. Development managers need to be
managing their team in way that a valuable library of development assets is built and they need to ensure that those assets are reutilised whenever there is an opportunity to do so.
Te list above is not exhaustive and barely scratches the surface on challenges related to software development. Many of my readers will be able to add many more challenges. I guess that is what makes software development interesting, solving those challenges and enabling organisations to achieve competitive advantage through the effective and efficient use of technology.

Technorati Tags: software development,software architecture,project management,relationship management,resource management IT assets

Agency Compensation - Variables that Impact Pricing

It's tough to make predictions - especially about the future.
                                                                    - Yogi Berra

How much will it cost to build an x for us? Where x stands for Website, Microsite, Facebook Page, Mobile App (or even a House, a Bridge, an Aircraft Carrier). Tough question, right? The answer is, "It depends". What kind of x do you want?

Unfortunately, this question is asked by clients of their agencies every day. Given the recession hangover, fortunately it is still being asked. I find that a little education helps either avoid this overly, simplistic question or more productively, it helps point to a method for finding an answer. The approach pretty much has to do with helping your client (as well as your team) understand the variables that impact pricing.

While on the topic, in the spirit of precision, I like to define terms. In general, the price of services and/or deliverables is made of two components: fees (pretty much labor) and costs (usually pass-throughs, such as travel, licenses, equipment, etc.).

Below is a list of some of the variables impact the price of a project. As I hope you can see this list will generate some pretty interesting discussions that, if handled, properly will result in a level of professional empathy that should elevate all involved

• objectives’ clarity / validity
• strategy integrity / clarity
• project duration
• time of year   -   for info on an ugly confluence of factors, see Use It or Lose It
• program complexity
• state / quality of assets, briefing, brand and style guides
• 3rd party involvement (e.g. other agencies, technology vendors, email / sweeps vendors, client-internal parties [legal, IT, etc], client-external partners [other marketers])
• scale & volume (planned scale decreases pricing)
• review / approval process – including: cycle duration, feedback quality / consolidation, and number of stakeholders (e.g. marketing, legal, compliance, branding, etc.)
• specification quality / stability
• production value
• costs (e.g. photos, video, locations, research, technology, travel needs, etc.)

The old Triple Constraint is also a valuable concept to help frame an agency compensation discussion with clients and your team.

There's a wide range of things on the agency side that also impact pricing, such as available staff, their skills, their rates, etc. Is it fair to charge a client an Art Director's rate to do a Production Artist's tasks? Same answer, "It depends".


Let us know your thoughts or if you have some other major variables that drive pricing.

The use of mashups in the enterprise

A mashup is a technique for building applications that combine data from multiple sources to create an integrated experience. Many mashups available today are hosted as websites on the internet, providing visual representations of publicly available data.
I have been observing a new trend in the software industry where applications are there to serve data and not the other way around. Data is at the centre of the universe  and not the application.
Take twitter for example, it is all about the data and not the application. There are so many twitter applications available to serve the data. Business Intelligence proves that when data is utilised effectively it can help organisations to achieve competitive advantage and consequently make more money. Super,markets organise the products on the shelves based on data served to them via business intelligence products such as reports from data warehouses and other. Another example is blogging which is all about what the author is saying, the data. There are many different blogging providers on the internet and many more applications that enable bloggers to create their blog posts and publish them to their website.
History of mashups
Mashups have become popular within the last few years, along with the popularity of web 2.0. Early mashups used data to combine it with maps of photos. However organisations are becoming more interest in mashups for the enterprise.
Organisations are utilising mashups to combine their data from different sources to arrive at new, more creative ways, of utilising their data. Some of the uses may include combining data from multiple sources, apply business intelligence to it and display it to information consumers in a way that can help to utilise the information in a meaningful way.
Architecture of a mashup
There are some common architectural patterns utilised to create mashups. All mashups use REST (Representational State Transfer principles)
Data is the core element of any mashup. The data does not need to be stored in a database that is local to the application, It can be anywhere on the internet, served through web services serialised as XML or JSON. RSS feeds are another source of data for mashups because they are in easy to use XML format.
Web services are also utilised in mashups. They can be used to provide extra services to the data or used to transform the data on the mashup.
Developers should think of the mashup application as a combination of middle-tier and some business logic. The client is usually traditional internet or RIA applications.
The use of mashups in the enterprise
There is really no limit to how mashup can be utilised in the enterprise. Combining internally available data with information from the internet can deliver some interesting services to the enterprise. You may create a website to help customers to find service centres, on the same page you may want tot display local weather and traffic conditions.
Another potential application is the use of mashups to lookup data on the internet that would add value to the information available in the enterprise, You can use information from your CRM application and lookup extra data available from various sources on the internet in order to learn more about your customer or potential new customer.
Mashups offer great potential to enterprises by adding value to information that was previously unrelated and serving that data to internal information consumers to to deliver services to clients.

del.icio.us Tags: mashup architecture REST enterprise

Technorati Tags: mashup architecture REST enterprise

What makes a good software architect

I have recently read an interview with Ray Ozzie, Microsoft’s chief software architect where he spoke about his role as chief software architect and what makes a good software architect.
Software architecture is a very complex and vast topic. It definition can be vague and the definition of a software architect can also be vague at times. In the past 10 years of experience in the ICT industry I have met many high level CIOs. I was always surprised to hear from some of them that they found that there is no need to have a dedicated software architect, they said that the role can be fulfilled by the CIO himself in combination with senior software engineers.
If the software engineer is competent in software architecture then in practice you have someone performing the role of software architect.
I have seen many definitions of the core competencies of a software architect. Some of them were so extensive that it would be hard to define the role.
Ray Ozzie’s says that a good software architect are the ones that have spent time building and debugging applications. He says that one can learn a lot by reverse-engineering applications. The more systems you develop and debug, the more you develop an understanding of what good and bad practices and design patterns. “It is the library of patterns that defines a good software architect”.
Ray Ozzie’s view makes sense. A good architect should have plenty of experience in order to develop a comprehensive knowledge of the patterns to use build applications.
A good software architect is the one that is always researching and learning about new technologies and how to apply them to solve real-life business problems.

Technorati Tags: software architecture design patterns software architect

del.icio.us Tags: software architecture design patterns software architect

The effective IT manager - the importance of relationship building

Relationship building is an important skill that any IT manager should possess and develop in order to be an effective manager.
The IT department delivers technical assets that an organisation utilises to support its daily activities. These technical assets impact the entire organisation and therefore the IT manager needs to have an in-depth understanding of how the organisation operates, the needs of each individual department and the correlation between between the requirements of all business units within the organisation,
Delivering effective IT services requires a lot communication with members from different areas of the organisation, it is not an isolated service, communication is a vital aspect of delivering effective IT services.
When communicating with other members of the organisation, clients or suppliers, they will respond better to you if they like and trust you.
It is much easier to talk to stakeholders, internal or external, if they like and are open to you in the first place.
Networking as a key to relationship building
Networking is essentially about building solid business relationships. To do this you need good skills in creating rapport and listening.
If you can make a connection with people on subjects you have a genuine interest in, their confidence in you will grow. Use this connection to engage them and then ask genuine questions and just listen. They'll often tell you what you need to know. Strong relationships will inevitably stem from commonalities discovered in simple conversation.
Being interested in people
Building good relationships means being truly interested in the people you deal with, both from a business and personal view. While discussing business issues is usually the main purpose of speaking with someone, finding out something personal about them takes the relationship to the next level and makes the business conversation much easier.
Learning about hobbies, special interests, family, leisure time activities, organisation memberships and anything else that might be of interest will help you make a deeper connection with your peers. It is important to also be able to “read” individuals as you communicate with them. Some people are not comfortable discussing personal matters, you should be able to quickly understand this and make sure that you are not invading other people’s personal spaces or being inappropriate.  
The important thing is what you do with the information you get. When dealing with team members, suppliers, clients and stakeholders try to mix personal information in the conversation. Every contact doesn't have to be about business. It's about peeling away the layers of formality and resistance to improve your chances of achieving what you want to achieve from the interaction.
Promoting a culture that favours relationship building
The best managers are those that develop a good sense of community within the team and across business units. Establishing a healthy culture as part of the community can help win the hearts and minds of clients, staff and suppliers. Culture is about sharing values and a healthy culture will be one that has people who care about each other. In projects it's about creating a 'community' within the project team that shares a common purpose.
It's not just a nice idea. A healthy culture can give a team an edge both in performance and in attracting good quality team members which is of vital importance. A good culture includes (often unspoken) expectations about the way things are done. In a project team these can be about how members respond to inquiries, how they greet each other, and how they behave when the pressure is on.
It's about treating people with respect and listening to their point of view. This doesn't mean you have to agree, but it does mean you respect their right to think differently and to express their views.
Cultures need leaders to set expectations and offer guidance on what's important. As a manager you will need to be aware that people are watching you for clues as to how to behave in relationships with others. Actions speak louder than words.
Relationship with suppliers
The contractual relationship is often one that's all about who has the power. One of the best ways that managers can improve their supplier relationships is to develop loyalty. Loyalty is a two-way street and to earn trust of suppliers, project team members need to demonstrate their value. It includes being professional and respectful in dealings with suppliers, being efficient in delivery of orders and specifications and working one-on-one when the supplier needs it.
In essence, it's about remembering that suppliers are people too and will respond well to a personal touch. When making a judgment about how their client will be treated, a supplier can't help but consider how he or she is treated by that organisation. Managers can cultivate supplier loyalty through open and honest communication. Keep them informed about major decisions and show them you have thought about how decisions will impact on them.
Good relationships are a key to success
It's easy to have good relationships when everything is running smoothly. But relationships really count when projects or related activities start to come undone. As with anything that involves people, establishing processes to encourage good communication and relationships and make clear expectations, provides the cornerstone for success in any project.

del.icio.us Tags: relationship bulding IT management project management business relationships

Technorati Tags: relationship bulding IT management project management business relationships