Heroes are great, they work overtime, they give it their all, tackle every crisis and sign up for every seemingly impossible task (do this 20 hour job in 2 hours). According to one manager, "these are the people that advance in a company."

This might come as a surprise, but in reality, what might seem like a good thing is actually bad for projects, bad for the company and bad for the team (the so called heroes and everybody else).

Heroics harbor bad practices

Every project management book I know of that has anything to say about heroics declares that it is a bad practice, a classic mistake. 

Projects frequently run the risk of becoming dependant upon heroics when heroics are the norm.  Yet, heroics seem to be the one aspect of a team that leaders and managers revere.  When a project fails, blame is often shifted to those that didn't give it their all or the heroes who simply couldn't run faster than a speeding train.

Truth be told, heroics exists because of poor project management or poor leadership.

According to Steve McConnell,

"...emphasizing heroics in any form usually does more harm than good. In the case study, mid-level management placed a higher premium on can-do attitudes than on steady and consistent progress and meaningful progress reporting. The result was a pattern of scheduling brinkmanship in which impending schedule slips weren't detected, acknowledged, or reported"¹

Heroics harbor several bad practices. Here are only a few, I'm sure there are many more: 

• Heroics to meet deadlines only guarantee future tight deadlines
• Heroics burns people out, rendering them ineffective
• Heroics leads to inaccurate and unrealistic schedules and estimates
• Heroics minimize the efforts of those who actually plan and are realistic about schedules and work effort
• Heroics promote the neglect of sustainable and dependable processes

A Culture of Heroics

I have worked for several companies that elevate the "can do attitude" to the extreme. In these environments, people tend to get distinguished for "going the extra mile".  A can-do-attitude is often equated with loyalty and commitment.  Don't get me wrong, there is some truth to that last statement. I'm all about overtime, dealing with crises head on, giving more when necessary and advantageous. It is when these practices are 1) revered and 2) normative (the way business gets done), I say that the company is dangerously immature and unstable.

The SEI Capability Maturity Model defines the lowest level of maturity for a software company (Level 1) as,

 "ad hoc, and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization, and not on the use of proven processes"²

At CMM Level 3, a company is implementing an "effective project management system". Implied here is that individual heroics are not what makes projects succeed, but rather that the company operates according to a proven set of standard processes. Essentially, the capability of a company is organization itself, not the talents and the superior capabilities of a few people.  

The bad side to heroics

In battle, the hero is often the one who risks or even gives his life. They are the ones who run into a foxhole with two grenades to take it out during an ambush.  Eventually, the foxhole is taken, the hero may be dead as well as members of his team.

Could the team have avoided the ambush if there was proper training, preparation and planning for the mission? Could the team have benefited by having considered all potential risks - areas that an ambush was likely? Could the battle have been won had leadership laid out a well-planned battle strategy?  

It would be worthwhile to consider where your organization stands regarding heroics.  I would be interested in other drawbacks to heroics, comments?

¹ http://stevemcconnell.com/rdenum.htm

² http://en.wikipedia.org/wiki/Capability_Maturity_Model#Level_1_-_Initial

Working as a Developer at Falafel is.... well, I'll just let the video speak for itself. 

Hard Work At Falafel

The Project Management Institute (PMI) is the authority in the area of Project Management (PM) and has created the leading standards on PM including the Project Management Body of Knowledge (PMBOK). PMBOK is an internationally IEEE recognized standard and it is the standard used in establishing the Project Management Professional (PMP) certification.

If the above paragraph doesn't make your head spin, just look into the requirements for PMP certification. I've been reading numerous articles and blog posts about whether such certification is necessary and worth the investment. One PMP holder suggests that the cost for certification can reach up to $5000 plus a huge investment in time!

I think of the PM's I have worked with over the years and none (including myself) are PMP certified. Yet, many articles I've read seem to indicate that PMP certification is starting to become very important in the marketplace. I quote one author who says, "The exam tests you on PMI's terminology, processes, and process boundaries. What the PMP does not demonstrate is our competency as project managers or our skills in applying our competencies in real-world situations."¹  This, however, can be said of most certifications I believe.

I've read a few articles that make the case for PMP certification. These mostly have to do with personal, professional advancement. One author presents common excuses, my favorite of which was this, "PMP sounds too much like "p1mp," and I don't condone e$_cort services."  (Note: I've purposefully changed the text hoping it will prevent any offensive AdSense ads).  

Anyway, what I'm wondering, and intend to research, is this question. How important is having PMP certified staff in software development /consulting organizations that provide the entire development team to its clients?

More later.

The situation is that you have a medium to large scale project you need developed. You don't have an in-house development team or one that is available.  Additionally, creating a new team is not an option.  Basically, you need to go outside of your company to get this project done.

Here are five quick tips to help you effectively screen vendors.

1. Consider Multiple Vendors

Unless you have experience with a particular vendor, look at several.  This is no different then hiring an employee. Make sure the vendor can understand your business needs and can speak intelligently to both the technology and the business domain.  Consider their core competencies, certification and experience.  Insist on speaking to past customer references.

2. Technology Considerations

Technology Bias

This depends.  If you actually don't know much about technology, platforms and so forth, you will not be able to determine whether a vendor's recommended technology is based on the vendor's preference, or based on your business needs.  There are a few things you can do here. 

a). Require vendors to justify their technology recommendations in their proposals.

b). Hire an independent resource to help you evaluate vendor recommendations or to perform a technology review based on your needs.

c). Beware of technology bias (unless you are already committed to a specific technology). Many smaller vendors focus on a specific technology like Microsoft or Java, etc. On the the other hand, vendors who focus on a specific technology are often extremely competent in that technology - consider this.

Here are some comments a vendor might say that exposes his/her technology bias:

"We develop in XYZ because we've determined that it is better than anything else on the market."

"Everybody is using this technology."

"This technology is the wave of the future."

Here is an honest statement from a vendor:

"I don't know squat about ABC technology and whether or not it will meet your needs, but I am an expert in XYZ and have determined that it will meet your needs."

Untested Technologies

Developers are developers because they love technology and they especially love the challenge of those on the bleeding edge. RUN AWAY FAST from any vendor who recommends using the latest technology, methodology, development platform, etc.  The last thing you need is to have your project become the test bed for some new, unproven technology. Remember, new technologies demo impressively, don't be lulled into early adopting.

3. 100% Developer Commitment

If you are providing full-time work, make sure the vendor agrees to a named developer or more to work exclusively on your project for its duration. It is not unreasonable for the vendor to require that you agree to a minimum number of hours per week per developer.

CAUTION: It is not uncommon for smaller vendors to take on Out-Tasking projects (small low-effort projects and development tasks). If you are providing full-time work, it is fair that the vendor grant you exclusive use of his/her development resource.  Furthermore, a vendor who needlessly overworks their staff (excessive hours beyond full time) is a slave-driver and doesn't deserve your business.

4. Phased Approach and Status Reports

Make sure the vendor agrees to a phased approach and weekly status reports. Run away from any proposal that doesn't give you visibility into the project (the blackbox approach).  You want to make sure that that you have check points throughout the development lifecycle. This is a good point to bring up in an independent review (see below).   

HINT: An experienced vendor will assume this. Ask about the development approach they use. If they don't offer this, you'll need to ask. While this is not a disqualifier, it is a red flag.

5. Independent Review

Have the vendor agree to an independent review of their work at points during the development process.

An honest vendor will not only agree to this, but will consider it good for the overall project.  I have been on both sides here and in every case, it resulted in further insight that only improved the overall project.

The process you use to select a development team is as important as the development process itself. It can be the factor that makes or breaks your project's success.

Well, I'm finally blogging again.  I've managed to get DasBlog up and running.  It is amazingly simple. It's really just a matter of getting the site copied properly over to your hosting service (if you are hosting on a service) and setting the permissions correctly.  For a service, I am using WebHost4Life which has excellent support I must say.

TIP: It is critical that you set the right permissions on the three subdirectories and don't forget to include DELETE permissions or you won't be able to delete blog entries. I know from experience!

\content
\siteconfig
\logs

All is explained thoroughly in the Setup instructions.  

At the moment, as you can see, I'm using one of the supplied themes while I work on my own. This is another aspect of DasBlog that is very simple and I'll post more as as I delve into this.

Thanks Steve for turning me on to DasBlog and for tips in getting it running!

So what am I going to blog about?  Numerous topics: Development, Project Management, The People Factor, Work Ethics, Technologies, and more. 

Stay tuned.

P.S. This blog was written with Windows Live Writer - a great initial experience.