Building software is like building a house in many ways.  When building a house, we have to have a good foundation, strong pillars, proper plumbing and wiring, and so on and so forth.  When building software, we need to have a good design, clear and concise code, proper wiring of components, etc.

There is one subtle difference between building software and building a house though.  Usually when we build a house, we rarely make large renovations such as adding a story, moving around walls and windows, putting in a new electrical system, or modifying the foundation. Software, on the other hand, needs to be modified and updated quite often due to changes in business caused by new opportunities, changes triggered by the economy, mergers and acquisitions, and so on.  Life expectancy of a software product is generally between 3 to 5 years before major updates are required.  A great number of software products require such updates much earlier in their lifecycle.

In the world of software something that works is not necessarily something that can be easily modified, extended, or maintained.  General observation is that the chunk of cost of software is not what’s spent on building it in the first place, but what it takes to maintain and extend it over the years.

There are several attributes of quality software.  I will list the most important ones from business standpoint below:

Reliability

Software functions each and every time in a predictable manner.  You can’t afford to have your “Save” button save your documents sometimes but not others.

Maintainability

It’s easy to maintain software.  Fixing a bug, for example, does not spawn another bug.  Or moving your database to another server does not require code changes.

Scalability

Software can easily keep up with business growth and does not require code modifications as the user base or usage grows.  This also goes hands in hands with efficiency, which is another attribute of quality software.

Extendibility

It is relatively painless to add new features.  Also the addition of new features does not break old features.

Reusability

The entire software itself or certain parts of it can be reused to create new software to address other business uses.

There are many other attributes of quality software, for example, usability, security, fault tolerance, etc., hence a lot of thought goes into building a quality product.

The Challenge

When building software, quality is something that is baked in from the beginning, and can’t be sprinkled on top after the fact.  Also creating quality software requires additional time, effort, and possibly investment into proper tools.  This creates an interesting problem for business users and the technical leadership alike: how to balance quality of software with investment that may or may not bring any positive ROI.

There are software development methodologies such as Agile that promise quality software with minimum time-to-market.  The problem with such methodologies is that if not understood correctly and followed properly, they do not yield promised results.  I have come across many companies claiming to use to use Agile, for example, that are only disguising their chaotic software development under Agile’s name.

I evaluate each situation and devise a plan accordingly.  Quality of software is definitely important to me, but having an entrepreneurial mindset, I understand and appreciate business challenges as well.  For experienced technical teams creating quality software even with time and budget constraints is relatively easy.  For teams that are not as experienced, this remains to be a challenge, that often times result in major disasters.

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.

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!