According to the 2009 CHAOS report published by the market research firm, the Standish Group, IT Project failure rate increased in the last 2 years of recession.  No surprise.

According to the report the rate of successful projects that were delivered on-time, within budget, and with the required features, dropped from 35% in 2006 to 32% in the last two years.  Also the rate of failed projects increased from 19% in 2006 to 24% recently, which included projects that were deemed complete failure and either never delivered, or delivered but never used.  The rest of the projects were considered challenged, those that were delivered late, with incomplete features, or went significantly over-budget.

As IT leaders do we see something wrong with this picture?  Keep in mind that out of projects that are usually successfully delivered, some are trivial to begin with, while some others start out with a bigger-than-required budget due to over-estimation.  This consideration drives the rate of success as reported by Standish even further down.

There have been numerous people who have written about how the lack of user involvement, unrealistic expectations, poor requirements, poor design, scope creep, etc. play a role in the failure of IT projects.  I do not disagree, but I think the problem is much more deep-rooted than what is generally pointed out.

I view these high failure rates as a direct result of:

• Incapable IT Leadership; and
• Incapable Technical Leadership

Keep in mind that IT leadership is not necessarily the same as the Technical Leadership.  I consider IT Leadership as high-level IT executives that are aligned with the business, for example, CIO’s, CTO’s. etc.  Technical Leadership, on the other hand, consists of Technical Architects, Solution Architects, and the like.

Lack of user involvement or unrealistic expectations, for example, point straight at the failure of the IT leadership.  IT leaders must make sure that they have proper processes as well as resources in place to involve and educate the users.  They are also responsible for convincing the business one way or the other, and analyzing and mitigating any risks before they become cause for failures.

Similarly it’s the responsibility of the technical leadership to ensure that proper requirements are in place before they embark on their journey of design and implementation, and that their designs actually do address all the business and other requirements.

Whatever the reasons, failure should not be an option.  If a project fails, I believe it’s because the leadership failed to do their job.

With budget cuts that come with the recession that’s still holding strong, as well as the ever increasing complexity of IT projects, I see the rate of success driving even further down the next time the Standish Group publishes it’s CHAOS report.  I really hope that I am wrong, but without a major paradigm shift in the IT and the technical leadership, I really do not see how that would be possible.

Management style is the general way a manager uses to manage his teams.  Some managers use a particular management style because that’s the only style that they are aware of.  More mature managers know different styles and can quickly adapt to any style to their advantage depending upon the situation, the capabilities of their teams, and the nature of tasks that need to be performed.

In this article I will go over the 4 general management styles, and explain how IT managers can best use each to their advantage.

1. Directive Democrat

The manager involves employees in the decision making process, but closely monitors them in the implementation of each decision. 

This management styles works best when your employees are capable of performing the job, but usually require a high amount of support from you.  It also works well as you are starting to get to know your employees and giving them a chance to prove themselves. 

This style of management usually fits most situations, especially in IT, as long as your monitoring practice does not interfere with the work your employees are performing.  There are ways to closely monitor without alienating your employees, some of which I discuss in another article, 5 Steps to Stellar Team Management. 

2. Directive Autocrat

The manager makes decisions unilaterally and closely monitors employees in the implementation of each decision. 

This management style works best when employees are neither willing nor capable of performing the job and require high amounts of support as well as guidance. 

This style of management is also notoriously known as micro-management.  Generally in IT if you come across situations when employees are neither willing nor capable of performing the job, then you have a bigger problem to solve.  Either your employees are incompetent and must be replaced, or there is something that they are trying to tell you but you are not paying attention.

3. Permissive Democrat

The manager involves employees in the decision making process and also gives employees latitude in the implementation of those decisions.  

This management style generally works best when you have mostly senior level employees who are willing and capable of doing the job, and require minimal support as well as guidance. 

As great as this style of management sounds, it can be risky if you do not know your employees well, or lack a long-term working relation with them.  A permissive democrat employee is sometimes viewed by his employees as a slacker, or the one who lacks interest.  Generally in IT this kind of a manager is one who finds himself in a management role but has no or very IT background to be able to guide or support his subordinates.

4. Permissive Autocrat

The manager makes decisions unilaterally but allows latitude in the implementation of those decisions.  

This management style generally works best when your employees require a high level of guidance, but a low level of support.  In other words, they are not sure about what needs to be done, but they are well capable of carrying out any assignments that they are tasked with. 

In IT this style of management is practiced by managers who find themselves in extremely fast paced environments where they can’t afford the time to make collaborative decisions, or when the manager views himself as an IT guru and does not trust his subordinates with influencing decisions.

Over the years I have come across a slew of management styles, some formal, some informal, some great, while others… well you get the idea.  During my own management career I drew upon best practices from my former bosses as well as management gurus in order to come up with something that was effective and yet easy to implement.  Here I’ll share with you a summary of my management style, which is based upon my general philosophy about employees that:

1. They come to work hoping to make positive contributions
2. They work hard if they clearly know what they are supposed to do
3. They are motivated when they feel being part of something bigger than their job
4. They put in their best effort when they feel empowered, are guided, and are provided with the right tools for the job
5. They improve when they are given sincere, honest, and timely feedback 

The following 5 steps I present to you are indented to be a general guideline and not hard-and-fast rules.  Since each team and each environment is unique, you will most definitely have to tweak these steps to best suit your personality, your team, your environment, and the task at hand.  See my article on different management styles for more information.

1. Define Clear Goals

The reason most teams fail in achieving their goals is because they do not have any goals to begin with.  As leaders or managers we must take the time to define and clearly communicate reasonable goals for our teams at regular intervals and track the progress of such goals throughout those intervals. 

One key success factor in achieving goals is to ensure that we pick the right goals.  Goals we choose must be meaningful, move us closer to our departmental or company vision, and should be relatively unlikely to change during the time interval we choose them for.  It does not mean that they cannot be changed at any cost, but if we keep changing goals midstream as a general practice rather than an exception than the whole exercise becomes counterproductive pretty quickly. 

2. Communicate Goals

The way we communicate goals to our teams has a profound effect on the successful realization of such goals.  We must not only make sure that our teams completely understand the goals, but also that they are sincerely committed to achieving them. 

The practice that works best for me is to set “Team Goals” each quarter.  Initially I do not assign any goals to particular individuals.  At the beginning of each quarter, I hold a team meeting to discuss what the goals are, why each one of them is important, gather feedback, answer any questions or concerns, revise some of the goals in the light of feedback received, and finally assign goals to individuals.  Even when I assign goals, I make sure that everybody understands that I am only assigning “ownership”, and that each goal still remains as a “team goal”.  This exercise takes several hours, but yields great results because a) each team member clearly understands our short-term vision; and b) each team member appreciates being part of something bigger than just a set of 5-10 items assigned to them. 

3. Track Progress

Defining and properly communicating goals is only half the battle; realization of those goals is the other half that leads us to the final victory.  First and foremost, we as managers must genuinely believe in the goals we define and be sincerely committed to achieving them.  Then we must help individuals on our teams achieve their goals and promote an environment where team members help one another in the realization of their goals.

Everyday I casually discuss goals that are in-progress with my team members on an individual basis to stay in the loop.  I try to do this without alienating them or making them feel that they are being micro-managed.  I allow them plenty of liberty in how they approach specific problems, but just by holding intelligent conversations sometimes makes them see things that they would have ignored otherwise.  It also helps me to assess any risks as early as possible, and allows me to find opportunities where I can help. 

Then I also discuss each goal and its progress each week with my entire team in our weekly meetings.  During this exercise I deliberately go over all the goals, even the ones that we all know have not been started yet.  This serves as a great reminder to all and keeps everyone on track.  Discussing goals in weekly meetings serves a couple of other essential purposes.  Firstly, it helps with knowledge sharing, which reduces the risk for me in case someone working on an important goal gets sick or gets hit by a truck.  Secondly, it helps the goal owner draw upon collective wisdom of the entire team, making him more confident in decisions that he makes.

The idea that a particular goal is owned by one individual but all team members are stakeholders is usually foreign to many people in the beginning.  However once they give it a shot, they are usually amazed by its power and how sometimes it can literally help achieve the unachievable. 

4. Reward and Celebrate

Managing teams is in some ways like raising children.  You reward them for good behavior, and they will outperform their own selves the next time around; you ignore their positive contribution and they will quit trying out of disappointment.

While small financial rewards can usually go a long way, that’s not the only kind of reward I use to motivate my teams.  When an individual or a team performs great, I make sure that a) they know that they have done something great; and b) they get the due credit for their achievements.  First and foremost, I recognize good performance one-on-one through appreciative and congratulatory dialogue.  Then I proudly highlight any success in our team meetings.  Finally I also look for opportunities to highlight success with external entities, for example though department- or company-wide e-mails. 

5. Analyze Results and Provide Feedback

Human brain is wired such that it learns best from experience.  No matter if the results come out to be phenomenal or pathetic, it’s important for us as managers to provide opportunities to analyze the outcome and learn from our own experience. 

In a meeting at the end of each quarter I take some time to go over our past quarter’s performance and discuss how and why certain things turned out to be better than expected while others left much to be desired.  I conduct this exercise in an open forum where each team member has a chance to speak and enlighten the rest of the team with their viewpoint.  This is a time where great process improvement ideas also come about.  

It is important to highlight anything that positively effected our results, and see if it’s possible and feasible to somehow make it a permanent feature of our process.  More often than not it’s not something that we can formalize, but by discussing it for a few minutes gives everyone a subconscious sense for it which helps in other similar situations in the future. 

One key thing while analyzing negative results is to stay positive, be forward-looking, and encourage our teams to do the same.  There is hardly anything we gain from finger pointing or criticizing external elements.  Where we can potentially gain is in coming up with objective ideas to minimize the occurrence of such negative instances so that future attempts can be much smoother. 

So there you have my 5 steps to stellar team management.  If you implement these steps and gain positive results, I would absolutely love to hear your story. 

Wish you the best and stay tuned for more!

A great manager is one who is well-respected and is liked by his team members, peers, customers, and higher-ups alike.  He is skilled, competent, and delivers results. 

What traits set apart a great manager from the crowd?  In this article I will discuss 5 traits of a great manager with the right attitude to succeed.  While the article is geared towards technology managers, the ideas discussed apply to other managers as well.

Trait #1: Trust Is Sacred

Trust is hard to build but easy to break.  A great manager takes every opportunity to build trust with his team and goes above and beyond in trying not to break it.  If there are times when he can’t keep his promise, for example, he takes time to genuinely explain why.

Similarly, a great manager trusts his team members and promotes an environment where they can trust him and openly share with him.  There are no secret agreements, no closed door meetings, no lying or hypocrisy, no back-stabbing, no credit stealing, and no unhealthy politics.  Decisions are made on the basis of merit, and are open to discussion if there are disagreements. 

Managers that promote trust in their workplace unmistakeably always gain a loyal and motivated employee base, and come out light years ahead of their peers who for one reason or another prefer a more political environment.

Trait #2: I Respect You, You Respect Me

Respect a person, and he will do the more (James Howell).  If you respect your employees, they will not only genuinely respect you back, but do whatever it takes to not loose that respect from you.  Yes, that includes working extra hard to get the job done, just so that they can hold up their image in your eyes.

A great manager promotes a culture of mutual respect and takes every opportunity to enforce it.  He does not demand respect, he rather earns it.  He also takes a leading role in showing his team how a culture of mutual respect promotes a fun working environment where people can open up to each other and bounce around ideas without the fear of offending someone.

Trait #3: No Idea Is Too Dumb and Conflict Is Healthy

A great manager never shuts down any idea because his mind is already made up.  Instead he believes in the power of collective wisdom, and gives all team members a fair chance to register their feedback.  Once all the feedback has been received and debated, a great manager tries to build consensus.  No team member is left feeling that their idea was disregarded because it was too dumb, or it wasn’t given a fair chance for any other reason.  Instead the manager makes sure that everyone understands the pros and cons of what is decided and why.  Rather than fearing conflict, he embraces healthy debates held in an environment of mutual respect.

This attitude goes a long way in gaining employee loyalty and ensures that everyone involved will put in their best effort in achieving success.  Moreover it promotes better decision-making where everyone understands that they have a fair chance to get their point heard and discussed, and that every decision is made in an unbiased way in the larger interest of the business.

Trait #4:  We All Have A Life Outside of Work

It’s really important for great managers to have a balance in their own lives, as well as to promote that balance within their teams.  With the right amount of planning and prioritization, there should be no reason for anyone to work long hours except occasionally.  Some project management and software development methodologies, for example, prohibit anyone from working more than 40 hours a week; exceptions are only allowed in the last week or so if required.

A manager who consistently puts in crazy amount of hours at work is usually viewed by his employees as incompetent.  If you work extended hours as a norm rather than an exception, you should try to bring a balance in your life.  If for some reason you must work crazy hours, make sure that you find a way to do it from home so that your employess do not know.

Trait #5: Do You Have Everything You Need?

Consider yourself being tasked with hanging a picture frame, but you are not provided with a hammer.  Now you might get creative and use some other tools to drive the nail into the wall, but it will most definitely take you longer and the results might be sub-par. 

All jobs require proper tools to do it right, and it can’t be more true for any kind of technology projects.  A great manager uses his skills and experience in finding ways to minimize workload, actively looks for opportunities to help, and ensures that his team gets all the required tools and resources to complete their work.  The results are usually no less than phenomenal.  But if you cut corners, you usually end up paying for it in the quality of results and the time it takes to perform the required workarounds.

• A team of peers with clear accountability, shared responsibility and open communications. Each role is accountable for a specific share of the quality of the overall solution.
• Advocacy for all key constituencies that must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
• Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.

There are 7 advocacies that are represented in the MSF Agile Team Model. In my opinion it’s imperitive that these advocacies have proper representation in order to ensure success of a given project. Since MSF offers a stretch-to-fit approach, it’s possible to map these 7 advocacies into fewer role clusters as determined by the phyical size of the team.

Following are the advocacies and their respective focus as presented by the MSF Team Model:

Product Management

Goals

• Understand, communicate, and ensure success from the standpoint of the economic customer requesting the solution.

Functional Areas

• Marketing
• Business Value
• Customer Advocacy
• Product Planning

Responsibilities

• Acts as customer advocate
• Drives shared project vision/scope
• Manages customer requirements definition
• Develops and maintains business case
• Manages customer expectations
• Drives features vs. schedule vs. resources tradeoff decisions
• Manages marketing, evangelizing and public relations
• Develops, maintains, and executes the communications plan

Program Management

Goals

• Right solution is delivered at the right time and all expectations are understood, managed and met.
• Deployed solution will meet qualities of service & business objectives, and be viable in the long term.

Functional Areas

• Project Management
• Solution Architecture
• Process Assurance
• Administrative Services

Responsibilities

• Drives development process to ship product on time
• Manages product design and specifications
• Facilitates communication and negotiation within the team
• Implements and ensures standards
• Maintains the project schedule and reports project status
• Drives implementation of critical trade-off decisions
• Develops, maintains, and executes the project master plan and schedule
• Drives and manages risk assessment and risk management

Development

Goals

• Implementation, estimates, high quality maintainable code and unit tests.

Functional Areas

• Technology Consulting
• Implementation of Architecture and Design
• Application Development

Responsibilities

• Specifies the features of physical design
• Estimates time and effort to complete each feature
• Builds and/or supervises building of features
• Prepares product for deployment
• Provides technology subject matter expertise to the team

Quality Assurance

Goals

• Ensure solution quality.

Functional Areas

• Test Planning
• Test Engineering
• Test Reporting

Responsibilities

• Ensures all issues are known
• Develops testing strategy and plans
• Conducts testing
• Reports test results

Release/Operations

Goals

• Timely readiness and compatibility of infrastructure.

Functional Areas

• Infrastructure
• Support
• Operations
• Commercial Release Management

Responsibilities

• Act as advocate for operations, support and delivery channels
• Manage procurement
• Manage product deployment
• Drive manageability and supportability trade-off decisions
• Manage operations, support, and delivery channel relationships
• Provide logistical support to the project team

User Experience

Goals

• Provide user documentation and training
• Understand and communicate users’ context, and ensure usability from user perspective

Functional Areas

• Technical Communications
• Training
• Usability
• Graphic Design
• Internationalization
• Accessibility

Responsibilities

• Acts as user advocate on team
• Manages user requirements definition
• Designs and develops performance support systems
• Drives usability and user performance enhancement trade-off decisions
• Provides specifications for help features and files
• Develops and provides user training

For some companies migrating to Agile from other traditional methodologies, this may not be the case. I have worked with companies that have well-defined and assigned roles for Business Analysts, Database Administrators, Front-end Developers, Back-end Developers, etc. When such companies move towards Agile, they face a problem of optimal resource allocation and utilization.

As an example, a developer may not be productive while a DBA is creating new tables in the database and writing stored procedures. Once the DBA is done with his tasks, he may not have enough to do until the start of the next iteration. Since Agile is iterative, and iterations can’t overlap, this may result in poor resource utilization and may adversely effect the overall efficiency.

Before starting to implement an Agile methodology within your organization, it is important to make sure that your IT human-resource infrastructure actually supports it. While Agile may work in companies with specialized IT roles, it is definitely not designed and optimized for those scenarios.

While I have been successful in implementing many of the Agile practices such as earlier stakeholder involvement, EDUF, iterative development, code refactoring, unit testing, continuous integration, etc. in a relatively short amount of time, I still have to deal with the fact on a daily basis that they have to have very good estimates too far in the future. They must have this information from a budgetary standpoint and in order to be able to make executive decisions in advance about whether or not to proceed with a given project.

I have tried my best to explain how the Agile estimation works, and how trying to estimate too far in the future could be a wasted effort, but after all the time and energy spent, I am beginning to think that perhaps the Agile philosophy is not for all mindsets after all!