How to Add People to a Late Project Without Making it Later

Many of my readers should be familiar with Brooks' Law, as quoted in Fred Brooks' Mythical Man Month:

Adding manpower to a late software project makes it later

The thinking for this statement is primarily that, when faced with tight deadlines, a software development team would spend more time getting new team members up to speed than they would just doing the work themselves. And so, people have taken this statement for granted ever since the book was published. But is it true?

I've had three times in my career where I was the one brought onto a project that was running late (in one case, already past the deadline and over-budget too). In each case, I did something different to bring the project back on track. In all fairness to Mr. Brooks, my experiences were generally for much smaller projects than what he was talking about, but I believe that my experiences could easily be applied to larger projects.

Start small and simple

One project I helped turn around was an internal work tracking application for one of my clients. The project had fallen behind primarily because of extremely aggressive timelines and expectations at the outset. The team really had no chance of finishing the project on time from day one, and unexpected changes pushed the project even further behind. When I arrived, I saw that the team had slightly less experience than I did with this particular technology, but they were quite competent and very familiar with the business need that we were solving.

To turn this project around, I didn't want to waste the time of the developers on the project any more than I had to, so despite the fact that I had skills to do anything on the project, I focused on doing simple, straightforward work normally done by a junior developer. I started with finishing the user interface for a list page, then I finished all of the similar pages. After I gained some familiarity with the project, I moved into some more simple but time-consuming tasks on the project. This allowed the developers already on the project to focus on the more difficult aspects of development. We finished the project a day before our drop-dead date given to us by the business leader.

Select your targets carefully

Another project I helped turn around was an eCommerce site for another of my clients. The project had fallen behind because of a combination of scope creep and trying to bend the selected eCommerce framework beyond its capabilities. To make matters more difficult, some of the features were beyond the abilities of the developers involved. When I arrived, the team's project manager was working to stop the scope creep, but the development team was focusing all of their time on a small number of the most important (and difficult to solve) problems.

In this case, focusing my time on making as much progress as possible wasn't the right solution. The team was clearly getting stuck on a few specific issues. Since I was the senior programmer on the team, I took over responsibility for fixing the most difficult to solve problems which freed up the junior developers on the team to finish the numerous but easier-to-solve issues. We were able to eliminate the backlog list fairly quickly after that and deliver a satisfactory website to our customer.

Sometimes process is the answer

Another project which I helped turn around was a highly-customized eCommerce application for another client. Both companies agreed that an Agile approach would be better for this project, and so each sprint had a fresh set of deliverables. The client was not happy, though, due to the fact that we couldn't deliver features fast enough. We also were not happy, due to the unusually high stress this project caused. When I arrived, there were seven client contacts giving us suggestions for features or enhancements, and all of them felt like their suggestions should be the highest priority.

The first thing I did, and truthfully the only thing I did, was persuade everyone that choosing a contact on the client side to serve as the Scrum master was in everyone's best interest. After that person was chosen, we told him our capacity for each sprint, and he was responsible for setting our priorities accordingly. After everyone settled into their new roles, we were able to spend less time managing the project and spent more time delivering features. We were happy because we were under less stress. The client was happy because the got more features each sprint.

Conclusion

Adding people to a late project can indeed help turn it around. But it's important to add the right people to a project. Diagnose the cause of the problems associate with the project, then assign new people to address those specific problems. Only then will you be able to turn around badly running projects.

How to leverage a Project Administrator effectively

In my second post in my series about Leadership vs. Management relating to IT, I talked about how project managers need to anticipate problems, decide which issues are worth fixing, and remove obstacles for their teams. Most IT people have worked for a "project manager" who merely ran reports, scheduled meetings, and constantly asked people for their status. In that article, I talked about how this second type of project manager really should be called a project administrator. What I didn't talk about, though, was what do you do if you suspect that you have a project administrator instead of a project manager?

Determine if you have a good project administrator or a bad project manager

Merely noticing that the project manager does a bad job doesn't necessarily make them a good project administrator. Here are some differences between a good project administrator and a bad project manager:

	Good Project Manager	Good Project Administrator	Bad Project Manager
Attention to Detail	Very detail oriented, but pays special attention to the most important details	Very detail oriented, but is unable to tell the difference between important and unimportant details	Not detail oriented
Interviewing	Great at eliciting the details that are important for the successful completion of the project	Good at eliciting all of the details associated with a particular area or feature	Has own agenda during interviews
Scheduling Meetings	Schedules meetings when they are needed, invites the right people	Schedules meetings when asked, invites everyone	Schedules meetings when asked, invites the wrong people
Project Planning	Understands when extra time is needed and plans accordingly	Schedules project plan according to timelines given	Plugs schedules into project management software and hopes for the best
Mitigating Issues	Works with team to solve important issues, lets unimportant issues slide	Works with team to solve all issues	Lets rest of team handle all issues
Communicating Issues	Raises potential problems to the people most able to fix them	Raises potential problems to everyone on the team	Raises issues to the people most likely to give pleasant answers

Identify your project leader

The most crippling problem that I see of projects led by project administrators is that the team lacks focus. When objectives are clear and the project is running smoothly, it is easy to feel like the leadership is adequate. But when the objectives become unclear or the project stops running smoothly, the team loses focus and several individuals attempt to step into the leadership void. To prevent this from happening, choose your leader before the project starts.

Decide if you need a manager

Do you need an explicit manager? Managers typically are tasked with ensuring that each person on the team is doing their job efficiently and to mitigate issues when they arise. If your team lead can serve this role, or if you are running an Agile project and the business stakeholder for your project can serve this role, then you may not need an explicit manager. When in doubt, don't include a manager in the project, and bring one in if it proves necessary.

Play to your administrator's strengths

Good project administrators are very detailed oriented, so give them responsibilities that play to their strengths. Most project administrators are great at scheduling meetings, providing regular status reports, etc. But most project administrators are also good at testing software, reviewing contracts, watching for missing details, etc. In general, look for detailed, repetitive, and straightforward tasks and your project administrator will shine.

Limit the information that the administrator receives

Because most project administrators don't have the hands-on experience necessary to know the difference between important details/problems and unimportant ones, try to limit the information that they receive. Generally I'm a fan of making all information available for everyone, but project administrators really should be on a "need-to-know" basis. Otherwise you risk having them overreact to an unimportant detail, which can distract the team from what is important.

Ensure that the roles are properly communicated

Finally, if you try to do all of this without the project administrator knowing, you will fail. Either the administrator will sense that their role is being diminished and they will force themselves in, or they will become confused and stop functioning altogether. Tell them what you are doing and why. Best case is that you have identified a training opportunity for a motivated employee. Worst case is that you can take some of the administrative tasks away from your business leaders and software architects and allow them to focus on the tasks that only they can do.

Other posts in this series

June: An introduction to Leadership vs. Management

July: Is a project manager the right person to put in charge of your software project?

August: How do you manage an Agile software project?

September: How to leverage a project administrator effectively

October: Getting programmers to see the value in management

November: The Peter Principle and software architects

December: Creating a leadership team to make your software project a success

I'm not impressed by your Klout score. Here's why.

As I've been getting more active on social media, I've started digging into Klout to see if I should care. (If you are new to Klout, I suggest you go to the Klout site to get an overview of what their score is.) Recently, I ran across this article that described one person's inability to get hired because of his Klout score, and his subsequent efforts to raise it which led to job offers and speaking engagements. Clearly Klout matters. But should it? I went through my own Twitter network to see if there was a correlation between qualities that I admired and high Klout scores, and after I was finished I was not impressed with Klout. Here are a few examples why.

Klout doesn't break down score by topic

"Bill" is fairly well known in technology circles for one particular type of technology. He attends many conferences and speaks at many more. He also tweets about new features and techniques for this technology. He also tweets about sports. And movies. And food. And his sleeping habits. I'm sure you get the idea. While Bill has an impressive Klout score of 66, Klout doesn't separate buzz that Bill generates because of sports vs. his professional life. And Bill seems to generate more conversations about sports than he does anything else. While Bill seems to be a great guy and an asset to the technology community, his Klout score simply cannot be compared to other technology guys to see who is more knowledgeable or influential in their areas.

Apparently high volume, even if low quality, is good for your Klout score

"Mike", on the other hand, pretty much only talks about social media-related topics on his Twitter account. He also has a healthy Klout score of 68. So does that mean that Mike would be someone to hire for a position or a speaking engagement? I've read several of Mike's articles, and they consistently start by stating a couple of vague, obvious points. Then right when you'd think that a truly informative, insightful conclusion is about to appear, his articles stop. But Mike tweets frequently and has a HUGE following, which leads to his high score.

High quality is rewarded, just not to the same degree

"Thomas" consistently posts high quality content on Twitter. His posts, though, are generally targeted towards people new to one particular concept when its most vocal supporters are fairly advanced. As a result, his engagement with others is somewhat lower. His Klout score of 57 is still respectable, but it's clear that Klout values his contributions significantly less than others in the technology field.

You're an expert in what?!?!

Finally, when I looked at my own Klout score, I was surprised to see that apparently my most influential topic was RabbitMQ. I was even more surprised after I looked at Wikipedia to find out what RabbitMQ is. Apparently it's an open source messaging system, but I never tweet about messaging systems and most of my posts about open source software are about how over-hyped it is. Somehow, Mac OS X Snow Leopard and Cisco made the list too, despite my ignorance of those two topics. It's tough to take the scoring system of a company seriously when it is so ridiculously far off on my own areas of focus.

Conclusion

Given these problems, it is tough to justify using a Klout score as a major criterion in a job search or in looking for presenters for a conference. However, Klout appears to do a good job in measuring an individual's influence using social media. Here are two areas in which I would use Klout heavily:

• I would never hire a social media marketing expert without a high Klout score
• If I needed a sales person in an industry whose target audience is on social media, a high Klout score would be an important criterion in choosing a candidate

In both of those situations, you want someone who knows how to generate attention using social media, and Klout is probably as good a way as any of assessing them. 

That doesn't mean that if you're not a sales person or a social media marketer that you should ignore your Klout score, or that it doesn't matter. While I don't put much faith in the score, other people clearly do. So it's reasonable to go through some efforts to raise your score, just don't lose perspective.

Why IT pros may be their own worst enemy in getting a chair on the executive table

This is the fifth in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

In this month's continuation of this series, I'll use the issue of whether the CIO gets a seat at the executive table as a proxy to discuss whether the CIO is respected within the organization, and how IT professionals can unwittingly sabotage their own chances of getting this respect.

You'd think that the CIO already has a seat at the executive table. In many companies, this is not the case. According to the Financial Times, only half of CIOs sit on the operational board of their company, and less than a third report to the CEO. So just because the CIO has an executive-level title, they clearly are often viewed as less important than, say, the CFO or COO. In the age of such pervasive technology that is vital to both smooth day-to-day operations and game-changing innovation, companies that don't have a CIO at the executive table are putting themselves at risk of their competitors passing them by. Technology professionals blame business people for this, but how much of this is the fault of technology pros themselves?

In order to answer this, we must first look in more detail at different attitudes prevalent within IT and how they would mesh with the stages I mentioned above. Here are the attitudes of IT professionals I've encountered in my career:

Combative - These IT professionals generally believe that the business people they work with are incompetent and should therefore be worked around rather than worked with. A combative CIO is sometimes a master at technology, but cannot understand (and doesn't wish to understand) why others aren't as knowledgeable. Such a CIO would want a seat at the executive table merely because he/she doesn't trust the people on the executive committee to make the correct decisions.

Compliant - These IT professionals generally believe that the business people own IT, and they view themselves merely as service providers to the business leaders. A compliant CIO is usually up-to-speed with technology, but often lets business drive innovation and only takes leadership around cutting costs. Despite being a follower rather than a leader, such a CIO would see himself/herself as a peer to the other C-level executives, and therefore believe that he/she deserves a seat at the executive table.

Collaborative - These IT professionals realize that technology is used most effectively when business leaders and IT professionals work together to create solutions. A truly collaborative CIO would be up-to-speed on both technology and business issues, and would constantly bounce around ideas with his/her business peers. A collaborative CIO would want at seat at the executive table in order to help shape and direct business strategy to make the most of available and emerging technologies.

It should be pretty clear to anyone who isn't himself/herself a combative CIO that a combative CIO doesn't belong at the executive table. He/she simply does not have the ability to build the personal relationships necessary to build trust. In fact, a combative CIO is likely to alienate his/her peers to the point where he/she would create a Stage 1 environment within the company and be viewed as a cost of doing business.

Most compliant CIOs probably believe that they belong on the executive committee due to the fact that other C-level employees within the company are. But it's tough to take someone seriously as a leader when his/her goals are limited to cutting costs and implementing the visions of the other leaders. Such a CIO would push his/her organization to adopt a Stage 2 environment - respected as a vital part of the business but still viewed as a cost center rather than as a source for innovation.

Most collaborative CIOs believe that they belong on the executive committee because they do. These are the leaders that have the vision to utilize technology to best achieve business objectives. Their vision would be such that they would push their organization into a Stage 4 environment. He/she would be well-positioned to ensure that the technology that the company is using is well-suited to achieve the company strategy and vice versa.

Finally, it is important to note that even the best CIO can only do so much to change the culture of an organization. A collaborative CIO in a Stage 1 organization probably won't get anywhere quickly - the business is already predisposed to seeing any mistakes, real or perceived, as proof that the CIO can't be trusted. It is unlikely that a qualified, collaborative CIO would stay long in such an environment. Likewise, a combative CIO could very likely ruin the trust present in a Stage 4 environment. So even though technology is so pervasive in today's business world, it takes the right CIO and the right environment to get a CIO on the executive committee.

Other posts in this series:

May: Levels of function (and dysfunction) IT can have with business

June: Why Stages 1 and 3 are not viable long-term stages

July: IT as a Service Provider May Be Bad for Business

August: When technology acts as a true partner to the rest of the business

September: How IT professionals can be their own worst enemy in achieving Stage 4

October: How your Stage would affect your management practices

November: How your Stage would affect your hiring practices

December: How can an organization reach Stage 4?

How to Manage Agile Software Projects

In my third post in my series about Leadership vs. Management relating to IT, I will talk about how to manage Agile software projects. Before I do that, though, I feel that I need to clarify the difference between true Agile and the pseudo-Agile used by most service organizations that I'll call "Iterative Waterfall".

As I discussed in my post about Agile a few months ago, the goals of any project leader who is truly taking an Agile mindset to their projects are to reduce wasted effort and to see value from the project as soon as possible. However, most service organizations' customers are focused primarily on two questions before the project gets started:

1. How much will this cost me?
2. How long will this take?

As we'll see in a moment, the methods that people have created to eliminate wasted effort and minimize the time before realizing value make it extremely difficult to answer these two questions. The result is that companies make a compromise by setting the scope of the project first, then creating a timeline for the effort, and then releasing the software in small batches on a regular basis. Iterative? Yes. Agile? No. Again, the point of a true Agile project is to reduce wasted effort, which means being able to easily adapt to changing priorities anytime during a project. People still call that type of effort "Agile", though, so I feel like I need to address it here.

Managing a Pseudo-Agile Project

Managing the actual effort during the progress of an Iterative Waterfall project isn't much different than managing the progress during a pure Waterfall project. Here's a rough overview:

1. Define your scope.
2. Organize your desired features into logical (and roughly equally-sized) groups, preferably groups that when completed represent usable software. This is like pure Waterfall in that you have milestones built in, but unlike pure Waterfall the milestones are equally spaced in the project plan.
3. Decide in which order your groups of features must be developed, and organize your project plan.
4. As the project continues, track effort and make adjustments to your timelines/scope/daily effort as necessary.
5. When a change in scope is needed, have contentious discussions about whose fault it was that the needed feature was missed during the requirements gathering process.

Managing a True Agile Project

Since Agile is meant to be, well, agile, managing these types of projects is significantly easier. Essentially, you need someone to manage scope for each sprint, but otherwise Agile teams are usually managed by a technical lead. How does this work?

1. The business leader determines what features are needed in the near term.
2. The software team estimates the amount of effort needed to implement each feature.
3. The business leader and software technical lead negotiate what features will go into the next release.
4. The delivery team meets each day to inform the group of their progress. Slower members of the team are helped and trained, and perpetually slow members of the team are removed.
5. Repeat steps 1-4 as needed until the features requested are not worth the effort of putting in.

Yes, removing most of the management for a project makes most middle managers uncomfortable. But the purpose of management is to ensure that teams and individuals have what they need to succeed, and this process does that wonderfully. The need for managers is greatly reduced, freeing up the business leader to focus on the value that the project brings without the overhead of the now unnecessary managers. This should free up managers to focus on adding more value to the organization or finding other portions of the organization to simplify and improve.

Other posts in this series

June: An introduction to Leadership vs. Management

July: Is a project manager the right person to put in charge of your software project?

August: How do you manage an Agile software project?

September: How to leverage a project administrator effectively

October: Getting programmers to see the value in management

November: The Peter Principle and software architects

December: Creating a leadership team to make your software project a success