First, make sure you define your project with the right people. In the beginning of this project, I was working based on a series of conversations with my client’s top executive. The top executive and I were on the same page, but the two directors were confused about what the project was doing. When I re-defined the project with the three of them together, we all started working towards the same goals.

Secondly, pick the smallest team that can be effective to meet your goals. This client has a very strong team based culture. While this leads to a high degree of staff empowerment, it also sometimes means that everyone expects to be involved in every decision. Knowing that previous projects had become bogged down in this bureaucracy, we comprised our core team of the strongest subject matter experts available. As we worked through various components of the system, we pulled in additional resources where necessary and made sure all the team members were communicating well to their colleagues. This allowed us to move rapidly through requirements definition, application testing, and finally projet approval.

Third, make sure you have clear expectations for your team. This may involve teaching your team how to do their work since they may not have participated in a similar project before. Even worse, they may have participated in a similar project that didn’t function well and have developed bad habits. On our team, we stressed that the team members were not expected to know everything. But they were expected to know who needed to be involved in each piece of the project and to pull those people in as appropriate. They were also expected to keep their supervisors and colleagues informed about project progress and to use their supervisors and colleagues to help resolve any issues.

Fourth, it is imperative to get the right technical skills on board. In Billings, there is a serious shortage of experienced programmers. So we used remote programmers through a service called oDesk. I managed the requirements definition, communication with the programmers, and primary quality assurance. This ensured that the client’s staff on the team were focused on their responsibilities…the functional aspects of the system. The approach allowed me to tap into the global talent pool to find the right skills, and helped my client keep development costs under control.

Finally, consistently confirm your understandings of your projects priorities (Cost vs. Time vs. Scope). In this case, the client strongly preferred a consistent monthly cost and a full set of application features to delivering on a specific date. As a result, we moved a little slower than was technically possible. When we had to adjust the schedule, I confirmed again with the client that their preferences had not changed. In the end, we delivered within a few weeks of our best estimate (on a 14 month project) and the client was very satisfied.

Most of these learnings weren’t necessarily new to me and they may not be new to you. But looking back, they were probably the key items that made the project successful. Hopefully, they’ll help you in your next project.

This past week (actually late August 2008), I achieved the Project Management Institute’s highly respected certification – the Project Management Professional (PMP). Unlike many certifications, PMI places a priority on verifying that a candidate has sufficient real-world experience to justify the credential. Before candidates can even schedule the exam, they have to document over 4500 hours of project management activities and at least 35 hours of formal education in project management. There is also an ongoing commitment to learning which requires PMPs to complete at least 60 hours of professional development activities over a 3 year span. So I’m pretty proud of this achievement.

The PMI method for managing projects, outlined in the Project Management Body of Knowledge (PMBOK), is extremely rigorous. Only the largest of projects would implement the entire methodology as described in the PMBOK. However, there are some great takeaways for smaller businesses.

1. Project management is NOT status reporting. I recently ran across a posting for a Project Manager position for a local organization. They needed someone to manage a key system implementation. However, their view of what the PM should be doing was “making sure everyone was getting their work done”. A person who merely collects and distributes work status information is not doing project management. Make sure your project manager has the proper authority to make your project a success.
2. Managing change and communication for the project are the most important reponsibilities of a project manager. How these activities are performed should be carefully thought out and actively managed. It doesn’t have to a formally written document, but the approach needs to be understood and followed consistently on every project.
3. A project is “progressively elaborated”. This means you learn more about the project and adjust your plans accordingly as the project progresses. So don’t fall into the trap of believing that following a project management methodology prevents you from exploiting your advantages as a smaller business to move quickly and nimbly.

For many reasons, IT projects are infamous for having a low rate of success. Don’t let the lack of qualified project management be the cause of your project failure.

First and foremost, you may be struggling with the expense and value of training classes.  One of the big questions is always "Is certification worth it?"  This is a question at hiring ("This person has a ton of certifications, they must be good."), it’s a question when your employees want training ("Are they going to get this training and then leave?"), and it’s a question after the training when some employees may ask for a salary increase to recognize their new skills.

I’ve never put much stock in certifications myself.  But a couple weeks ago, I had an experience that may be altering my opinions on the subject.

Earlier this month, I attended a week long class on SQL Server 2005.  I’ve been using SQL Server for a while now and have gotten fairly proficient.  But there were many gaps in my knowledge and some things just weren’t fitting together completely.  So I decided to invest the time and money in the course. 

Now, this was a boot camp style course.  What this means is that the entire class is geared towards making sure you can pass an exam at the end of the week.  To do this, they work through the material of two 5 day courses in just 5 days.  I knew from prior experience that the typical 5 day course is just too slow paced for me.  So a boot camp seemed like a much more productive use of my time.

At the end of the course, I did end up passing the exam.  I now possess a MCTS – SQL Server 2005 certification.  Like I said, I’ve never placed much emphasis on certification.  But through the experience, I learned a number of things that have me thinking differently.

1. The value of the certification depends entirely on the person holding it.  There were 4 people in my class.  Besides myself, there was a programmer and 2 system administrators.  One of the two SAs had absolutely no prior database experience.  All 4 of us passed the exam.  But guess whose certification is absolutely worthless?
2. When looking at a person’s credentials, look for focus and depth rather than an endless list of certifications.  It would be very easy to go out and pass a bunch of tests unrelated to my focus areas.  But to do so would only paint me as a jack of all trades with no true expertise in any specific area. 
3. Training for IT employees is truly a form of compensation.  If your employees get certified and bring new skills to the job, that’s great.  But you don’t have to increase their compensation just because of their increased potential.  When they successfully apply their new learning to solve your business problems, then reward them for that.  Alternatively, if the employee has been using the technology for a long time and the certification recognizes their expertise in that area, then an adjustment may be merited.
4. You need to tailor your training plan to the individual’s learning style.  Some people do really well using self-paced learning at home.  Others do best in a classroom environment.  I shy away from eLearning because I have a hard time staying focused on the content when so many other things are going on.  I also know that the incremental cost of the boot camp style course is well worth it to me because I can handle the faster paced class.
5. If a person has a high level certification, make sure they have the experience to back it up.  Entry level certifications simply prove your familiarity with the subject.  In many ways, it’s acceptable to have a basic certification without experience (i.e., you can’t get experience if you’re not certified, but you can’t get certified without experience).  But the higher level certifications should be looked at closely to make sure their experience matches their training.

I really enjoyed my training and I’ve already found ways to benefit my clients because of it.  I still don’t care about the certification.  But it’s a marketing tool and I’ll use it as such.  Hopefully, my experience will help you know how certification fits into the training and evaluation plan for your IT employees.

I’m no Harvard MBA, but Ms. Ross and Mr. Weill have it all wrong. Companies that follow their advice are doomed to mediocre IT performance. Here are the six decisions they say are best left to non-IT execs, and why I think they’re off-base.

HBR: “How much should we spend on IT?”

Reality: Does the head of marketing decide how much to spend on accounting staff or tools? No. If your CIO or head of IT is not capable of understanding your business goals and planning a budget to meet those needs, then you’ve got the wrong person in that position.

HBR: “Which business processes should receive our IT dollars?”

Reality: It’s smart to selectively approve IT projects. But don’t forget that most IT funds are spent maintaining existing systems or on infrastructure requirements. Business executives forget about last year’s projects much less that project from 5 years ago.

HBR: “Which IT capabilities should be firmwide?”

Reality: This statement blatantly contradicts the author’s assertion that technical implementation details should be left to the IT execs. Again, if your CIO is not capable of understanding your business enough to develop an operational model that supports it, you need a new CIO.

HBR: “How good do our IT services need to be?”

Reality: The authors suggest to not let IT execs push for the “Cadillac” when a “Buick” is all that’s needed. Are you kidding me? Certainly all executives like to provide the best tools possible to their teams. But just try to imagine the CFO allowing the CIO or head of marketing to state how good the accounting services need to be!

HBR: “What security and privacy risks will we accept?”

Reality: Of the 6 points, this one is actually the most reasonable. The business needs to understand and accept the tradeoffs between convenience and security. But it’s the CIO’s responsibility to educate the business and help them find that balance. After all, the CIO is likely to be named in any HIPAA or Sarbanes-Oxley lawsuit!

HBR: “Whom do we blame if an IT initiative fails?”

Reality: If you’re thinking this way, it’s a bad sign for your business. Change your mindset now. You should be thinking, “How can I help ensure that IT initiatives helping me achieve my goals are a success.”

In the end, the HBR article fails to comprehend the true nature of IT’s role in the enterprise today. To be sure, there are companies who run their IT departments this way. But we know that companies that use IT strategically grow faster and are more profitable than those who don’t. Viewing the IT department as a cost center that needs to be tightly controlled by non-IT executives is certainly not a strategic way to do business.