Subscribe via RSS Feed

Category: Team Dynamics

IT as Great Facilitators Part 4

What Great Facilitators Know About Estimating

IT-Great-Facilitator-4Last post, I shared an exercise that helped teams understand how to develop a plan that is manageable and achievable. I call this “Commitment Based Estimation”.  Now, I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to be effective at facilitating estimation sessions,  I’m going to discuss how to select the best person to facilitate these sessions.

I typically find that the team-lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who can allow the team to own the estimate.

When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to constantly optimize an estimate, then the team won’t feel ownership. This is not how to get a Commitment Based Estimate.

Similarly, when an architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.

Now, you may be thinking: Does this mean I can never challenge a team? It does not. What is does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.

For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now, you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Good Facilitators Can Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic.  I talked about this in a past blog called “Attitude of Estimation”.  As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered.  Project Managers can offer perspective on dependencies and resource availability.  The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects, and the database team also need to weigh in.  Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

Have you ever been in an estimation session where the facilitator was more of a hindrance than a help?

I hope you have enjoyed my 4-part series on facilitation. If you missed them, here are the links:
IT as Great Facilitators Part 1
IT as Great Facilitators Part 2
IT as Great Facilitators Part 3

In my opinion, there are way too many people who take the facilitator role for granted.

I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them.  A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

Prototype Technologies are Ruining Your Prototypes

Prototyping-TechnologiesI want to challenge our thinking on how we use prototype technology in our world of software development. Are we using prototypes to help our business users all get on the same page and visualize a solution?  Or are prototypes targeted at our internal team, so they can understand what the resulting system “should look and behave like”?

Prototyping can mean different things to different groups. For purposes of this post, let’s use this definition:

A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from.

When I researched this definition, there were some key points that consistently turned up.  They include:

  • A Prototype isn’t the final product.It is designed to test a vision and illustrate a requirement for a final product. For example, if you want to design a car with the gear shift on the left side of the driving wheel, you could create a prototype with only that level of detail. It may not have a horn etc… Just enough to ‘prototype’ the proposed change.
  • A Prototype is used to eliminate ambiguity. In other words, it helps drive a common vision across project participants.  For example:  “Oh… so when you said make it smaller, you really meant tiny or minuscule. I see now”.
  • A Prototype is used to drive feedback. This helps an idea grow before making huge resource or financial commitments.  We might build a working prototype of an Internet Alarm Clock that plays your music stored in the Cloud on the Internet.  It may be fully functioning, but it is a one-off. Its purpose is to gather our initial reactions and generate additional ideas based on the working prototype.
  • Finally, a Prototype might be a Proof-of-Concept. This is used to test the feasibility of an idea and whether the initial vision can actually be delivered with the desired results. This is more of a design based prototype.

Why We Prototype

To summarize, prototypes can be used to:

  • Drive a common vision across stakeholders
  • Confirm our understanding of a desired end-state
  • Provide a forum for feedback among internal stakeholders and external customers.
  • Act as a proof of concept, flushing out the feasibility of an idea

Most prototypes serve one or more of the above the purposes.

These days, there are many tools for prototyping.  Everything from HTML for creating  working-light-weight prototypes for review to wireframe tools such as iRise or Balsamiq.  There are even PowerPoint files with “wireframe templates” in them to build wireframes and mockups using PowerPoint and it’s native tools.

So What’s the Problem?

In spite of the great tools out there, I’ve been in situations where these tools actually get in the way of our goals. They don’t help the business users get to alignment. In fact, prototypes created with these tools can actually drive a “compromise” in their design. Let me explain using an example:

I have three business users working to define a new “quick order” system for their web site.  The Business Analysts spend a couple of hours working with them to collect their vision for the new shopping experience and all the tweaks necessary to take their website to the next level.

We take these requirements and have a designer build a quick prototype so we can make sure this is what they wanted. The final wireframes (built in HTML or another technology) are then emailed around to the business folks for feedback.

Now Volleyball Sets In!

Volleyball starts when one group, in this case the designers, emails information to the users and then the users email back their clarification or changes and the cycle continues.

It’s like each side is sending something over the wall or volleyball net. And, just like in volleyball, if one side drops the ball (or gives up) the other side scores a point.

At this point, the  challenge  is to effectively create a  common vision across multiple stakeholders using email! (Hmmm, I wonder if this is how congress works.)

More often than not, the business gets the prototype to where it’s “Good Enough” and then approves it. They want to get going and hope they can tweak it as it is being developed.

Let’s see how effective this is at achieving our goals for prototyping:

  • Drive a common vision
  • Confirm understanding of a need
  • Provide a forum for feedback
  • Checking feasibility

I would argue that this process is extremely ineffective and delivers inconsistent results.  When someone says this is close enough, are they really saying they feel like we are all on the same page?

If it DID accomplish these goals, then any system that used this approach would have less change requests, less defects and lower overall development cost.

But there is a better way. The Lo-Fi way.

Enter Lo-Fi Prototypes

Here is another way to create and finalize prototypes.  Let’s go back to the meeting where the Business Analysts were collecting requirements.  After they collected the high-level requirements, they use actual post-its that are cut into screen widgets. For example, there are post-its in the shape of data entry fields, list boxes etc. You can even use fan-folded post-its looking like a drop down box.

Now we ask the business users to actually build their screens. Using the post-its, scissors and markers, they create a lo-fidelity prototype. Whenever possible, we print out existing screens, even screens of a competitor, and mark these up with post-its and markers.

The prototype is NOT designed to flush out usability or the end look and  feel. It is used only to enable the business users, as a group, to quickly build their lo-fidelity prototypes and share their vision and intent for the system.

I’ll emphasize that it is CRITICAL they understand that the final system will be a bit different due to design requirements, usability, branding, etc…

This approach is extremely effective and scalable. In fact, I have facilitated a small group of business users using this method to create more than 50 screens and report prototypes in a session.

There are a couple of great benefits using this approach:

  • The stakeholders feel ownership for the prototypes
  • It eliminates ambiguity, frustration and misunderstandings due to volleyball
  • Stakeholders can iterate immediately
  • They work as a group, helping drive alignment which results in less rework
  • Prototypes can be scanned into the requirement documents

At times, we give a few of the more critical lo-fi prototypes to a developer to create a hi-fi prototype (an HTML based prototype that can be interactive) over lunch.  And yes – I said over lunch! The users can then get a real understanding (feedback) on their vision.

So if you really want to use prototypes effectively, forget about all those fancy tools. This down-to-earth, friendly  approach will help you fast path collecting clear requirements and reduce confusion around the real needs and intent of a system, eliminating the pain of volleyball.

As a final note, I believe there is a place for using technology in prototyping. I am a fan of those tools. But I think we have gotten so technology focused, we tend to forget the real goal and use the technology appropriately.

What kind of prototyping tools does your team use? How do you think the post-it approach would go over in your environment?

What Abbott & Costello Can Teach Us About Software Requirements

Whos-On-FirstGrowing up, I used to love watching old black and white comedies, particularly Abbott & Costello.  If you’ve never seen their classic “Who’s on First”, you can find it right here on YouTube.  Feel free to watch it now (but be sure to come back)!

Briefly, this comedy skit is about Abbott explaining to Costello the names of the players on their baseball team.  The names of the players include “Who” playing 1st base, “What” playing 2nd base and “I Don’t Know” playing 3rd base.  Costello wants to know what the players’ names are, so he would ask “Who’s playing first base?” and Abbott would proudly respond “Exactly”.  A frustrated Costello asks “What is the name of the person on first base” and now Costello would reply “No, he plays second”.

If you have never heard the routine, you must listen to it to appreciate it. The link above should help. But I digress.

“Who’s on First” can teach us a great deal about the pitfalls of collecting requirements:

We can have two business users reviewing the same requirements document, each thinking it says something very different. It gets worse. In the real world of requirements, this confusion isn’t limited to two individuals. It spans the entire team, including the business analysts, testing team and developers.

The obvious difference between the “Who’s on First” routine and real life requirements, is that Abbott & Costello know they are having a communication problem.

In the real world, the situation is actually much more challenging.

The “Spellchecker”

Let me share with you an actual “Who’s on First” example that happens almost every time we collect requirements.  I call this the “Spellchecker” (and this is totally fiction, made up for illustrating my point).

Let’s pretend we need to add Spellchecker capability to our mobile application. We send out an RFP to various firms. In this example let’s say we send it out to Apple and Microsoft.

Apple responds and says they need two people working for two weeks.
Microsoft responds that they need four people working for six weeks.

We wonder: how does one company’s estimate result in four person-weeks while another is twenty-four person-weeks?  Did Microsoft pad their estimate? Or did Apple simply not spend the right energy on estimating and they pulled a number out of the air?

So we ask Apple: “What are the two people going to do for two weeks”? They respond that they will build two screens and one engine. The two screens will include the screen that shows you replacement words and a confirmation screen.  The engine is the actual “Spellchecker”.

Seems reasonable.

Then, we ask Microsoft: “What are four people going to do for six weeks”? They respond that they will be working on eleven screens and three engines and possibly some APIs.

Hmmm. We pause and ask: What are these eleven screens going to be used for? They explain the same two screens and engine that Apple discussed.

But they also have screens that allow you to add and maintain a list of “custom words” for your personal dictionary.  Further, they have screens that allow you to plug in a proprietary dictionary such as a medical dictionary or a special language.  That is how they got to eleven screens.

WOW! I never thought of that detail. Now I have to think of which version of the “Spellchecker” I really want.

If I want the two-screen version, I have to ask Microsoft to change their assumptions and re-estimate.  If I want the eleven-screen version, I have to provide the clarity to Apple and ask for their re-estimate. Most likely, I may want something in between. Maybe a seven screen version. I want the “custom dictionary of personal words, but NOT the proprietary dictionaries”. So I clarify and ask them both to submit a re-estimate.

Unlike Abbott & Costello who knew they weren’t communicating, in  the real world, we usually don’t catch our “Spellcheckers”. The BAs write up the requirements and the developers deliver the code.  We all think:  How difficult can it be to understand? After all, the business folks said they just want a Spellchecker! How much more straightforward can you get?

And later, when we deliver a solution that missed the point, the business will hold the BA and developer accountable! I mean it’s as simple as “Who’s on First”!

Taking the First Step

After sharing the “Spellchecker” story with the teams I work with, we actually use the word “Spellchecker” in our every day conversations to help uncover ambiguities and assumptions. It’s sort of a “keyword” around here.

Say we are discussing how we  can’t put the next release of our software into production until we fix all of the defects that our top executive just finished screaming at us about. The developers estimate that this can take two to three months.

Our manager responds that we are estimating out of fear and these defects can be squashed in weeks. There is no way he is telling the executives that they have to wait another “three months”!

Then, someone pop-ups in the heat of this conversation and says:

Time-out.  Do we have a “Spellchecker”? When you say fix “All the Defects”, we see there are over 50 defects in the system and we can’t imagine fixing all of those with four developers in a matter of two weeks.

Our manager responds:

50? No way!  We only need the Severity 1 defects fixed. There are only four of those defects.

And the team responds:

That makes a big difference. Yes we should be able to get that done in a couple of weeks. But are you sure that the Executives agree to only work on the Severity 1 defects?  It’s a Spellchecker to them too!

The Benefit of Acknowledging Spellcheckers

Not only do the teams I work with use the word Spellchecker to call out ambiguities, I have clients that have adopted this practice, calling out situations where they question whether  “are we really talking about the same thing”. (In fact, the spellchecker concept is so useful, even my family has adopted using it).

There will always be areas that slip in between the cracks. You can’t catch every Spellchecker. However, the real benefit of acknowledging Spellcheckers is the fact that everyone acknowledges that unintentional Spellcheckers, not individuals, can be obstacles to a team’s effectiveness.

More important, Spellcheckers often point to a two-sided misunderstanding.  Many times, when you uncover a spellchecker in requirements, the business person will say: I didn’t even think about that. I am not sure what I meant.

I’ll add one more example: When a business user identifies a defect in the software we delivered, we argue that this is an enhancement and not a defect. This is usually a Spellchecker in action and we are both right (or wrong)!

Now, Who Did You Say Is On First?

My suggestion is to introduce the concept of Spellcheckers to your team and ask everyone to speak up when they see Spellcheckers.  Share this with your business folks, management, and everyone else involved on the project. When you identify a Spellchecker, everyone can agree that no individual is at fault. It is simply a challenge in every day communication.

I’ll leave you with a final link.  I recently came across another short video that is a modern day technical version of “Who’s on First”.  I hope you enjoy this as much as I did. I especially like the punch line at the end.

Please comment and let me know about how Spellcheckers create confusion in your world and any other insights on the topic.

If you think others in your network or organization would benefit from learning about Spellcheckers, feel free to share this post using the tools below.

Photo Credit: Purple Slog

Everything I Know About Software Development I Learned from Elephants

The Swiss Army Knife of the Animal Kingdom

Elephant-2Last week, I talked about the importance of introducing the elephants in the room.  So now that we have the elephant in the room, let’s examine it and see what we can learn from elephant behavior and how we can apply it to software development. The irony of the “elephant in the room” metaphor is that it suggests that elephants are these large, bulky creatures that are imposing and not dynamic. In fact, elephants are one of the most versatile mammals on this planet. The elephant’s trunk is used to tear up food, so the elephant can digest it. It is a hand that can grasp objects, a means of drinking without having to bend over, and a way of  spraying mud on themselves to protect their skin from the sun. It is even used as a tool for  social interactions, to enhance their highly developed sense of smell, and to defend themselves from predators.

To deliver software predictably, we need to become dynamic, adaptable creatures as well. As the speed of technology gets faster and faster, we’re going to have to give up the idea of just doing one or two things really, really well. We’ll have to be like the elephants’ trunk. We have to know the foundation of coding, but not be married to any single language. We’ll need to understand the best practices of project management, but be flexible in our methodology and apply the best methodology to the best practice. We will need to master requirements facilitation, but have many different tools to gather requirements and to custom fit the requirements process to the appropriate projects.


Even We Can Become Extinct

If we are rigid and only do things one way, technology will pass us by and we’ll become extinct. However, if we are adaptable with our tools, practices, and methodologies, we’ll continue to evolve to meet the demands of business using the best that current technology has to offer.

In the past, the slower speed of technology may have meant that a method and tool would be useful for many years. In the fast pace of technology today, it is never the case that we can say that any idea, method, or tool works every time. We need to be constantly transforming ourselves, our ideas, methods and  tools to confront new challenges.

We may come to find more and more that projects are changed or canceled once we have gained momentum. Perhaps what made business sense when we started the project no longer makes sense due to new technology which has changed the marketplace. Rather than letting this disturb our equilibrium, we should begin to develop habits that allow us to shift rapidly and be adaptable to such change. Those in technology who can rapidly adapt will excel in tomorrow’s marketplace.

Being flexible and adaptable isn’t easy. It requires us to constantly let go of things that we know as true. Something may have worked for us before, but it may not work now. Or perhaps we have a perfect tool in mind for the job, but our client has a tool they like more. We have to let go of what has worked in the past for what it will take to accomplish the challenge before us.


And Maybe Dumbo Wasn’t That Far Off Base

One last thing we can learn from elephants is to use our big ears. Disney’s portrayal of Dumbo, the elephant with ears big as wings, wasn’t that far off base: Elephants have huge ears and an exceptional power of hearing.

As a predictable partner, we also need to always be using our ears. Not just to listen to what our clients are saying, but to really understand the meaning of what they are saying.

We can do this by maintaining a curiosity with our clients and what unique strengths and issues they have. Listening is a good first step, but when we are curious about our clients’ strengths and issues, then we have motivation to not just hear, but to understand.

Also, using our ears helps ensure that we are speaking the same language. It ensures that we are talking apples to apples and oranges to oranges. Our active listening helps our clients to know that they are being heard.

So next time you pop in the Disney classic about the elephant with the big ears, take note. Just like the underdog elephant who learned to fly, we can also use our ears to help us find success  with our teams and clients.

What Elephants Teach Us About Software Development

The Blind Man and The Elephant

SONY DSCSo there’s a treasure trove of stories and metaphors that revolve around elephants, and lately in my work with Geneca, I keep on running into elephants.

One of my favorite elephant stories that I’ve been coming back to lately comes from several sources in Eastern Philosophy: The Blind Men and the Elephant. In this story, several blind men encounter an elephant. One touches the ear and says the elephant is like a hand fan. Another touches the trunk and says the elephant is the branch of a tree. The one who touches the leg believes the elephant is a pillar and the one touching the tail believes the elephant is a rope.

This metaphor tells us that different people with different roles and perspectives will have different ideas of what the “whole” is. This reminds us that on projects, since each person can’t see the whole, we have to have good communication with each other to understand what the whole really is. And this leads me to the next metaphor that I keep running into:

Getting in the Elephant Habit

When I listened to “Last Lecture” by Randy Pausch, a Professor who had cancer and was delivering the last and most important lecture of his life, I was struck by the technique he used to address the most anxiety-producing topic in the room. What he said was: “My dad always told me, when there is an elephant in the room, introduce them.” Then, he goes on to talk about the fact that he has cancer, which everyone knows, but nobody wants to talk about.

To deliver software predictably means to always be introducing the elephants in the room. When there are things that everyone in the room knows about, but no one wants to discuss – politics, friction between team members, risks, difficult decisions no one wants to make — it is our duty as the predictable partner to introduce these elephants.

One of the best practices of predictable software delivery means that we are speaking the same language as our client, apples to apples, oranges to oranges. Because we are the predictable partner, and because we believe in the best practices of predictable software delivery, we need to step up and introduce the elephants in the room, even if it is difficult and perhaps risky to do so.

I’ve noticed that the first time you introduce an elephant in the room, it is not well received. It is as though you have disturbed a social norm. It makes people uncomfortable. Often the first elephant I’ve introduced is the friction between two members of a team. Everybody has noticed it, but everyone has consciously or subconsciously decided to accept this friction that negatively affects the team, rather than face the uncomfortable moment of calling it out.

What I’ve found is that after introducing the first elephant, the second becomes easier. After the second, the third is expected. After the third, people have adapted to this behavior, and even begin to call out elephants they see. It becomes a habit, a part of the team culture. And having a team culture of calling out the issues rather than sweeping them under the rug is what being a Predictable Partner is all about.

Next week, I’ll talk about what we can learn from elephant behavior and how that can be applied to software development.

So, can you learn to adapt, or will you go extinct?

Photo Credit: Martien Uiterweerd

Iteration Zero: Reduce Risk Before You Begin the Project

Reduce Software Project Risk Before Construction Starts

Sunglasses-and-RoadmapLast week we talked about the level of planning required to ensure that a journey (whether a travel adventure or a software project) be enjoyable, problem free and capable of delivering better results.

In the first stage of planning for our journey, we identified where we wanted to go and how we thought we’d get there. In software development, this can be thought of as business definition and understanding the business objectives. The second stage of preparation for our fictional journey — studying a detailed map and the purchase of travel gear — can be thought of as Iteration Zero.  This is where the team’s virtual assembly line is prepared. Finally, the third stage of swimming and running is the construction phase.

Iteration Zero sets up the groundwork for construction by implementing the reusable patterns and components in the application architecture and preparing the environment for a development team to be effective. This phase helps to remove the traditional Just-In-Time environment setup that often occurs in the construction phase. By adding an Iteration Zero, you are essentially allowing for time to be utilized more effectively and predictably during the construction phase.

One perception about the phrase “Iteration Zero” is that it implies an agile style of development. This is not necessarily so. The practices in “Iteration Zero” have been used successfully with several different development methodologies.

One of the major dependencies for an effective Iteration Zero is awareness of the success criteria of the project defined and agreed to by the business. They also need to be understood by the technical team(s) before the Iteration.

Creating a Forum to Ask Questions and Learn

One of the most important elements for executing Iteration Zero is the Workshop. The Workshop allows the team to see how the software is going to be developed from a process perspective. Additionally, it helps the team become familiar with the technologies, components and patterns implemented and added to the code solution. This begins the process of the team becoming immersed in the construction process.

In order for the development and quality teams to be effective in Iteration 1, the Business Analyst should begin creating the Business Rules Documentation. Iteration Zero provides them with a jump start from both the development team and the quality team.

Iteration Zero can also be used to identify risky technical aspects of the system. These risky elements should be studied to form a mitigation plan (during Iteration Zero) to learn as much as possible, as early as possible.

Hit the Ground Running

Although there are ways to prevent a project catastrophe, most of us have still seen at least one project land in the dumpster for a myriad of possible reasons. While there are risky elements outside of delivery that can hurt a project, adding and enforcing Iteration Zero is a great way to make sure your next journey goes faster, behaves more predictably, and adds more value to the business.

How is your team using Iteration Zero?

Photo Credit: Thomas Beck Photo

Credibility: The Key to Quickly and Effectively Building Trust with your Client and Teams

Bridge over smooth water

Building trust bridges relationship gaps. Here’s how to do it.

Have you ever had a difficult encounter with a client and then found it hard to reach out to them? Have you ever been in a client situation where your trust has eroded? How about with a coworker? Don’t be afraid to admit if you have, because it’s a normal part of life and can happen quite frequently. One of the many challenges we have with professional and social engagements is building and keeping trust. I call this the “trust factor”.

The Trust Factor

The trust factor is strengthened by many different behaviors: Following through on commitments, walking the walk, being true to yourself, evoking transparency, and maintaining accountability. Time, of course, is also a crucial influence on the trust factor. The time it takes to build trust with any one person can take days, weeks, or even years. But in business, we all know that we must make effective use of our time to build trust as quickly as possible.

Trust Factor

Building trust takes time and requires focus on doing what you say you’re going to do.

In order to successfully and effectively build trust in your professional relationships, you’ll need the help of your peers, team, and clients. Once this is accomplished, a cohesive bond can be formed between teams, which will ultimately foster productivity and results. In order to have trust, one must establish a strong sense of credibility. This can be achieved by:

  1. Establishing clarity around roles and responsibilities which builds a foundation that supports credibility
  2. Reinforcing credibility by holding yourself and your team accountable
  3. Sustaining credibility by working together to make and honor commitments

Step 1: Build a Foundation that Supports Credibility

Establishing Clarity around Roles and Responsibilities


Think of it this way: You want your house to have solid foundation when it’s built, right? It serves as your house’s main support. The same theory applies to your trust factor. A poor or weak foundation to your house results in costly, ongoing problems. Having poor credibility and lack of role clarity supporting your trust factor, well, you can imagine.

The first step in establishing a foundation for your trust factor is to clarify team roles and responsibilities. To do this, your team has to be able to answer the question: “What is my purpose on this team?” Their answers to this question will gauge your team’s understanding around their roles and give them an opportunity to establish their credibility. Everyone’s trust factor will be firmly supported once credibility has been established.

Many organizations have a lack of clarity around roles and accountabilities. This becomes a caveat to project collaboration, credibility, and success. The slightest miscommunication or misunderstanding can damage an entire team’s credibility and momentum. Without a clear vision of established roles, a team will scramble when a new idea or problem presents itself. In addition to creating an atmosphere of uncertainty and a lack of predictability and credibility, missed opportunities, rework and delays will surely emerge.

Trust Factor and Knowing Your Role

Know your role and you will better know the expectations others have of you.

Step 2:  Reinforce Newly Enforced Credibility

Hold Yourself and Your Team Accountable to Meet Client Expectations

The first thing you need to do here is eliminate mediocrity. It is our responsibility to call people out for under-performing and encourage improvement. Imagine the implications to a team when more than one person is picking up extra slack. Feels counterproductive, stressful, and hurts the team’s morale, doesn’t it? By being accountable, tasks will not fall through the cracks. As a result, your progress will remain strong. If you see an area in need of improvement, be vocal about it. Be true to yourself and your peers (Read: being at face value) while maintaining a high level of transparency. This  will reinforce a sense of trust within your environment. Accountability greatly evolves your trust factor and will take it to the next level.

Trust Factor, Knowing Your Role and Accountability

Hold accountable both yourself and those around you.

Step 3:  Sustain Credibility

Working Together to Make and Honor Commitments

Finally, work together with your peers and clients. Keep metrics that add value and make sure that everyone understands the purpose, goals and format of the metrics. This will add visibility on what each member of the team has committed to accomplish and will stimulate accountability. It is at this moment that trust is mutual with you and your client or peers. Throughout the project, the synergy  created from mutual trust will make your team run on all cylinders.

Teams that work together to build trust are more likely to succeed at it.


Be transparent with your team to maintain credibility. By following through on your commitments, you will continue to grow trust with those around you. Sustaining a mutual trust between your client and peers will remove crippling roadblocks, allow you and your peers to see goals clearly, and induce a high performance environment.

Get Started. Build Trust Today.

Can trust be achieved in a short amount of time? If mistrust exists, can it be eradicated? This, of course, is the million dollar question. By simply treating your team as your true teammates and allowing a more fluid, open channel of communication, trust will begin to develop and results can easily be obtained.  Work on obtaining clarity and agreement from everyone at the beginning and watch your team go into overdrive. Amazing things happen when everyone is on the same page, working toward the same goal, and sharing a dedication for excellence.

Do you always hold your team mates accountable? Can you think of a time when you could have been more transparent with your client or team?

How Internal Pressures Can Implode an IT Organization

Roadmap with cities and distances

Know where you are today. Be clear on where you’re going.

Last week, I talked about some of the many organizational pressures that can implode an IT team.  In fact, some of these may apply to other parts of the organization as well.  This week, I’ll take a look at an approach that can shed light onto solving these issues.

It’s All About Perspective

The ability to look inward in a truthful, non-self-serving manner is a phenomenal attribute to possess.  The same holds true when looking at an organization that you’ve helped create.  Allowing myself to pull out from working within the team to working on the team has afforded me valuable insights.  This ability to change perspectives is the best way to look around and objectively survey the landscape.

Once I change my perspective, the focus becomes applying a very simple approach that has been invaluable to me over the years.  Three steps: Where do we want to be, where are we now, and how do we get there?  In that order.

Where Do We Want To Be?

What may have worked well a few years ago may not be the optimal solution for today.  This is simply because our surroundings continually change.  So, resetting the baseline and re-establishing alignment can be a continual process.  Understanding how the organization will be measured and knowing what problems you’re trying to solve today will be the starting point to crafting your solution.  Not knowing where you want to be is like driving a car with a blindfold.  You’re bound to hit something and you won’t get anywhere.

Getting the right group involved is a great way to start the alignment process.  During that process, it may become clear that others have different agendas, goals and ideas on how something should be implemented.  Facilitating this group alignment on where the organization needs to be and establishing a common vision will allow everyone to head in the same direction.

This is also the time to make sure your goals will solve the problems as they are perceived today.  If silos exist or technology is scattered as I described last week, then perhaps one of the goals is to look at how to create horizontal technologies that can be shared amongst the silos.  The goal could be as simple as creating a shared platform which has an added benefit of getting the teams communicating more.

Where Are We Now?

This is where taking a step back is the most helpful.  Being immersed in something for an extended period of time gives us a single perspective of what we know to be true.  Because many teams have a lot of knowledge about what already exists (after all, they live it every day) it can be tempting to breeze through this phase.  Do not breeze.  Do.  Optimally, document the enterprise architecture of the technologies, processes and roles that exist.  You will most certainly uncover some interesting aspects of your surroundings that were previously based on assumptions.  If you have found this to be true in your experiences, please share in this blog discussion!

How Do We Get There?

This is the part where a roadmap is created.  This is typically the most difficult phase.  It has been equated to creating a solution to changing the tires on a moving race car.  It can be difficult, but do-able.

Not only is this the most challenging phase, but it’s also my favorite.  This is also the same phase where you should consider inviting the solutioning team from the first phase. They are invested in the destination, so it only makes sense that they should have some passion and energy around getting everyone else there.  Don’t go it alone.  Following this approach, you will begin seeing a team start to craft a common vision and a plan that is designed to accomplish what may have previously been thought as impossible.

The Bottom Line

Continually measuring and re-aligning has helped me immensely in preventing my teams from imploding.  This is not a tool that gets used once and discarded.  It’s designed to be used continually.  The frequency will be determined by the velocity of change in your organization.


  • How have you had to cope with organizational pressures and how did you get started toward resolution?
  • How did you engage the right people for the solutioning phases?
  • What obstacles did you overcome?
  • What other pressures have you seen implode or hurt an organization?

Photo Credit: Goldemberg Fonseca

How Internal Pressures Can Implode an IT Organization

Implosion1Last week, I talked about some of the organizational mindsets that lead to misalignment within an IT team. This week, I’ll look more closely at some of the specific pressures that can cause problems for the team and impact IT team performance. These are based on some of my own experiences in my role as an Architect.

Team Silos and Lack of Communication

Larger IT organizations often contain splintered groups that focus on either specific functional or technological areas. These groups can easily become silos. This can result in redundant efforts and solutions, dissimilar technologies, or disjointed entry points for business requests. More importantly, these silos may not easily communicate, inhibiting collaboration. Probable result: If a technology group makes changes and deploys, they run the risk of clobbering another team’s systems. Usually, they won’t know about it until production issues arise. The teams are neither in alignment on technology, people or process. This has the potential to bring progress within the IT organization to a standstill.

Pressure to be Bleeding Edge

Have you ever witnessed a technology team adopting new technologies for the sake of being bleeding edge? This desire to be bleeding edge is another factor that can cause pressure on the IT team. There are certainly many cases where new technology solves problems and creates additional efficiency. But what about the team that wants to utilize a new technology only for the sake of playing with new technology? It may perform the same function as the current technology, but just does it in a different way. Is there any value in that?  Does it help attract talent? Can it be adopted and integrated without any additional effort? Does it position the team to becoming more nimble? Does it align with long-term objectives of not only IT but the organization as a whole?

If some members of the team answer “yes” to these questions and some answer “no”, then the use of some new technologies can cause misalignment on the IT Team.  They may either have conflicting agendas or may just be out of alignment with how they need to accomplish the task-at-hand.

Teams That are Always Stretched

Stretching from time-to-time can be very healthy. It keeps a team aware of their limits and capabilities. It also helps a team to gel and rally around an effort that has a sense of urgency. Then, during the non-stretch times, it allows the team to think strategically, place more focus on refactoring which will allow it to scale for the next stretch. On the flip side of that, a team that is never stretched can have morale issues and may not deliver value at the velocity that is expected. But while the resulting atrophy isn’t healthy, teams that are always stretched are in worse condition. Stretching can result from task overload, following an antiquated process, working with unfamiliar technologies and working toward an unrealistic goal.

In any of the situations above, design and development decisions are usually made with the highest priority being: “Get this pain away from me as quickly as possible”. Decisions consistently made in this mode, usually create technical debt. If an IT organization consistently resorts to short term fixes, it compromises its potential and future progress and we begin to see implosion at the organizational level — not a sustainable plan.

What are some of the pressures has your IT team faced recently?


Next week, I will delve into some of the approaches that can be used to rectify these situations or prevent them from happening in the first place.