The Importance of Talent in IT

February 14, 2011

For a little diversion from Cloud Computing, let’s talk about the importance of talent in IT organizations.  Several weeks ago, while talking with a collogue about the Super Bowl game between the Green Bay Packers and the Pittsburgh Steelers, our discussion turned to the value of talent.  Player talent is highly valued in sports, but not valued as highly in the world of IT.

In pro-sports, player talent is viewed as a fundamental key asset.  If a player has more talent and gets a few more tackles in a football game; hits more home runs in baseball, or scores more baskets in basketball, than that player’s value can on the field and salary off the field can be many times higher than less talented peers.

Yet in many organizations, the talent of IT software engineers, project managers and architects is commoditized.  A standard bill rate or cost per hour is defined for IT roles and “rate sheets” are developed with published rates for various roles.

The standard rate sheet model assumes that all individuals in a given role produce the same amount of work.  Unfortunately, IT is more of a craft than a factory assembly line and the standard rate models may not be the best model to use.

The same individual talent differences that we observe in sports occur in IT.  Barry Boehm, in his 1981 book “Software Engineering Economics”, (, found that higher performing software development teams were up to 25 times more productive than lower performing software development teams. This is an astounding difference and one that may play a big part in why so many IT projects fail.

Boehm’s results have been replicated time and time again. More talented software engineers, project managers and architects produce substantially better products, faster and at a much higher productivity level.

I am not sure of all of the reasons why IT talent is commoditized, but one reason may be that we don’t spend a lot of time focusing on IT talent.  Instead, we focus on the latest tool or methodology, versus the talent of the individual using the tool or methodology.

Most professional sports have a large infrastructure of scouts, talent evaluators and minor leagues that try to identify talented players.  Sports also measures performance with every game. Maybe if IT organizations focused on identifying talented software engineers, project managers and software architects, than we would have fewer failed projects, more project successes and individuals in IT who have more talent would be treated as the super stars that they are, just as super star players in sports are treated.

Agile vs. Traditional Project Manager Role

August 17, 2010

A number of Agile authors suggest that the role of the traditional project manager on Agile projects is dead and should be replaced by the Agile Project Manager.  Although I have disagreed with this idea, I had never examined it in detail.

At a recent Agile Project Management Meet-up, I had an opportunity to examine this idea.  We had a facilitated discussion on the role of the “Scrum Master / Agile Project Manager”.  The facilitator was objective, did not favor any particular view of Agile and did not compare the Agile role with the Traditional Project Manager role.

Note: For the remainder of this blog, I will use the term “Agile Project Manager” to refer to both “Scrum Master” and “Agile Project Manager”.

After the Meetup, I documented the Agile Project Management responsibilities discussed in the Meetup in the table below.  I added Ken Schwaber’s ideas about the role of the Scrum Master, (noted in italic with an asterisk) and listed PMI’s PMBOK 2008 responsibilities for the Traditional Project Manager.

After analyzing the table, there appears to me to be little difference between successful Agile Project Managers and Traditional Project Managers. They have similar responsibilities and successful ones practice participative management.

To me, the main difference between the roles is in the way they are portrayed.

Agile Project Manages are portrayed as favoring a participative management style guiding self-governing Agile Project Teams (more on this in another blog).

In contrast, Traditional Project Managers are portrayed as favoring an autocratic, command and control management style; make all project decisions themselves; develop detailed Waterfall Project Plans themselves; assign tasks to project team members without their input; and are constantly “cracking a whip” to make sure that all team members are working as hard as they can to complete the project.

These views do not fit with my experiences and do not they fit with what the PMBOK says.  The PMBOK discusses a variety of management styles, and then states that project team members are key to the success of any project and recommends a collaborative team building style as the best way to run projects.

The most successful Project Managers that I know (Agile or Traditional) practice participative management.  They include project team members in in project planning, in project decision making and in project execution.  They focus on training and mentoring their teams to help them achieve project objectives.

Table 1 – Agile versus Traditional Project Management Responsibilities

Scrum Master – Agile Project Manager

Roles from Agile Project Meetup

Traditional Project Manager

From PMBOK 2008

Facilitate Rituals:

  • Stand-ups / Scrums
  • Demos
  • Retrospectives
Facilitate Project Activities::

  • Project Planning Meetings
  • Execution of Project Tasks
  • Project Status Reporting
Coach Agile Team in Rituals and in agile task execution
  • Develop Team Members
  • Work collaboratively to resolve project issues
  • Work with Stakeholders to set and manage their expectations
Remove Obstacles (Impediments*) Resolve Project Issues often using an Issue List (Obstacles or Impediments)
Track Progress & suggest corrections if needed

  • Burn-Down Chart for Sprint
  • Burn-Up Chart for tracking multiple Sprints that were needed for a Production Release
Track Progress and manage changes

  • Time, Schedule, Cost and Scope through Project Change Control
  • Earned Value Effort and Schedule Charts
  • GANTT Charts
Manage Project Budget Manage Project Budget
Develop estimates using Planning Poker (a modified Delphi technique) Develop estimates using a variety of techniques including Delphi and modified Delphi techniques)
Communicate with Stakeholders:

  • Product Owner
  • Team
  • Sr. Management
Develop and manage Project Communications Plan for all key stakeholders
Work with Product Owner to:

  • Help prioritize
  • Manage Scope
  • Coach
Work with Stakeholders to develop:

  • Project Charter
  • Project Management Plan
  • Prioritize and balance project constraints of:
    • Scope
    • Time & Schedule
    • Cost & Budget
    • Resources
    • Risk
    • Quality
Helps form Teams*

  • Works with Customers and Management to identify and institute a Product Owner
  • Works with Management to form Scrum Teams
Develops Human Resource Plan

  • Identify key Stakeholders
  • Identify and document project roles, responsibilities, skills, reporting relationships
  • Acquire, Develop and Manage Project Team to fill Project Roles
Responsible for the success of Scrum*

  • Is the driving force behind all scrum activities and ensues that the values, practices and rules are enacted and enforced*
Responsible to organization to achieve Project Objectives (Success)

  • Is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements?
Is a New Management Role* Traditional Project Management Role that has been around for numerous years.

1st Post – IT Excellence!

April 25, 2010

This is my 1st Post.  This Blog is about IT Excellence!

In today’s global economy, business organizations must constantly pursue excellence to remain competitive by:

  • Creating new products and services
  • Improving existing products and services
  • Reducing cycle times and cost
  • Improving quality and productivity
  • Innovating and constantly improve

The IT organization needs to supports the business’s quest for excellence by striving for IT Excellence, by striving to become:

  • Agile, Lean and Green
  • Customer, staff and people focused
  • Innovative and constantly looking for ways to improve its capabilities
  • Able to rapidly identify, develop, adopt, introduce and deploy new concepts, technologies, tools and practices
  • Constantly measuring its performance and using that information to better manage itself

The pursuit of IT Excellence requires hard work, people oriented change management techniques, agile and learn practices, excellent project and process management, and breakthrough & continuous process improvement and measurement.  The business can use many of these same techniques in its pursuit of business excellence.