Wednesday, October 24, 2007

New Blog URL

I've moved my blog to WordPress
http://joenay.wordpress.com/

Friday, October 05, 2007

The Measure of Success

What is the measure of success? For a project manager it may be bringing the project in on time and on budget, for a football team is may be considered a victory. I would challenge that both of these views are limited and somewhat short sided.

From a leadership standpoint the measures of success should be set at a much higher level. While these events are significant milestones, are they real success? I would say not always. So if these are not the true measure of success, what is?

Here is what started my thoughts on this subject. My son decided this year to play football. It has been a thrill for me, because he has put everything into this team. He is a first year player and so does not have the experience, but works his tail off. Well, the league rules state that every child must play a minimum of 10 plays per game. During the first game (which we lost) at least five players did not get the required number of plays. I made a huge issue of this with the head coach and he promised both my son and I that it would not happen again.

The second game, every player got their plays and even though we lost, the team was in much better spirits. Winning did not make the difference to these 10 year old boys, being part of the team and participating made the difference.

As a leader sometimes we are challenged with employees who have not defined their own measure of success, leaders can help these individuals make the choices to characterize success, if the employee is willing to take those steps. The most difficult challenge is when an employee’s goals are to get out of work at all costs, but that is a different blog altogether.

I have found the best definition of success comes from identifying one’s own values and principles. True success comes in the areas of our lives that mean the most to us; this may be family, faith, career, or whatever. By obtaining a core value success we establish our own personal happiness, and in the end happiness, true happiness, is what we are here for.

Friday, July 06, 2007

The Customer Dilemma

I often find the most challenging part of an IT project is working with the customer. Now I firmly believe that business should drive the technology and not the other way around. My favorite adage is the example of a car, the developer can tell you the best place to put the ignition and the best design for aerodynamics, but they should never be the driver, or “Never give the nerd the keys”.

The basis for every IT project should be the requirements of the project. These requirements should be developed with great care through a close relationship with the customer. This I am firmly committed to in every IT project that falls under my responsibility. So where is the customer dilemma that I’m talking about?

Well, that is the rub, the project’s foundation is the requirements, however, that is far from the end state. Some customers want to insert themselves into the design and development process. In my experience, allowing the customer this much access during the design and development phases will cause scope creep and most likely delay the project and lead to cost overruns.

Now some would argue that these are acceptable consequences for the benefit of the customer input. I would submit that this same benefit can be achieved through regular project updates and a solid change control process, without the same risk of scope creep, time delays, and budget issues. This will allow the IT shop to control the scope, cost, and schedule. If additional requirements are added through the change control process, they are scoped, budgeted, and scheduled and therefore are not delays.

The key to this process is customer education. Some customers are so used to having the developer at there disposal, with the ability to tap them on the shoulder and suggest a “slight” change in the project. The developer wants to be helpful and quickly implements the change, with little or no documentation. This slight change only took a “couple of days” to put in and the customer is happier. Right? All is well!

The project is scheduled to be complete at the end of the month and at the project status meeting the developer informs the project manager that he is a month behind schedule. Because over the past six months the customer “shoulder tapped” him about once a week. Now we have a gold plated application that is behind schedule and over budget. The same customer who had been doing the shoulder tapping is now upset with the project manager because his project is delayed for a month and is going to cost more money. Whose fault is this situation? The project manager is to blame; they must control the project, which in turn means controlling the customer.

As a customer is educated to the benefits of a solid change control process they will learn to embrace it. They will understand the impact of the change requests and understand the responsibility they have in the project. This will also help the developers focus on the actual work and complete the project on time and within budget.

The educated customer is happy and in full control of the requirements through the change control board, without controlling the IT development work. The end product will meet the needs of the customer and then everyone is happier. (Don’t we all wish it work this way every time?)

All this being said, the customer dilemma is very real; I wish educating customers were as easy as it sounds, but it takes a major paradigm shift. This is especially true in the world of re-organization that is covering the industry currently. It is also important to pick your battles, remember that the war is not won on a single battle, but through very small victories along the way. As you show your customers your can be successful and deliver a product that meets their needs they will be more willing to provide you with the needed support in the change control process.

Thursday, April 12, 2007

Change Control Policies

I have been following a few blogs over the past several months; one in particular is that of Joel Dehlin the CIO for the Church of Jesus Christ of Latter-Day Saints. His latest post was about the “Maintenance Monkey”. The challenge we all face in keeping IT projects and applications running and the continual cycle of “bug fixes”. I highly recommend you take a look at his comments. I wanted to add one more thought to this line of business and that is Change Control.
What a wonderful tool to utilize in managing, not only projects, but customers. A strong change control policy, driven by the customer, will assist in the reduction of maintenance. I have found that customers often do not understand what they are asking for, by driving them to a change control board, change requests that where once considered critical the customer will not even make it to a change request. By forcing them to defend the request to the board they must take a closer look at the request. The change control board will also reduce the number of request as they begin to see the impact and risk assessments of change requests and realize the true scope of what they are asking for.

I think IT shops get into a habit of not giving the customer enough credit for the ability to understand. This mistake is due to OUR faults in speaking in tech languages rather than in business languages. I agree that a good project manger, program manger, etc. is vital and should be on the CCB in an advisory position, but the CCB voting members should be customers with decision making authority.

Wednesday, March 14, 2007

Standards

I just returned from the National Immunization Conference in Kansas City, MO. Great BBQ and steaks! However, what I learned most was the affirmation of the idea that standards make the world go around. While speaking to a large group of highly qualified immunization professionals, including doctors, nurses, and highly educated pubic health professionals it hit me like a ton of bricks, they don’t understand what standards are, or what they do for us as information technology professionals.

I was asked why developing a new vaccine ordering system was so difficult, when in this day and age we can go across the globe and use our ATM cards and get money from our banks, why can’t we develop an interoperable immunization ordering system. My response was that the banking groups got together decades ago and agree to standard business practices and communication standards. During this process each organization was willing to compromise on certain proprietary business processes for the greater good.

In my current reading of Thomas Friedman’s “The World is Flat”, he discusses “10 Forces that Flattened the World”, of these ten forces one that hit home to me was “Work Flow Software”. The discussion of this topic came around to “standards on top of standards” and the two quotes that hit the spot were:

“Once a standard takes hold, people start to focus on the quality of what they are doing as opposed to how they are doing it. In other words, once everyone could connect with everyone else, they got busy on the real value add, which was coming up with the most useful and nifty software applications to enhance collaboration, innovation, and creativity.”

And:

“…software companies stopped competing over who got to control the fire hydrant nozzles and focused on who could make better hoses and fire trucks to pump more water.”

This illustrates the how we can use ATM’s around the world, the banking community stopped worrying about whose business model was best and focused on interoperability between systems. What a great lesson to learn. If every organization would remember that the work is more important than the process and accept the use of standards and design their systems within the framework of those standards, things would move much faster and efficiently.

Friday, March 02, 2007

States Visited

I found this cool site that allows you to create a map with the states that you've visited.

http://www.world66.com/myworld66/visitedStates



create your own personalized map of the USA
or check out our
California travel guide

Monday, February 26, 2007

Leadership Qualities

I am fortunate enough to have been invited to belong to a Mentoring Circle; this is a group of leaders and emerging leaders in the Coordinating Center of Infectious Disease at the Center for Disease Control and Prevention (CDC) where I work. I was invited to join the group by our Chief Management Official, Reggie Mebane an incredible leader.

At the last meeting we watched portions of a Federal Express Leadership video that discussed five qualities of a great leader:

  1. Challenge the process
  2. Inspiring a shared vision
  3. Enabling other to act
  4. Modeling the way
  5. Encouraging the heart

Since then I have been have been observing leaders who I admire at work, church, and other places and watching for these qualities and steps. It is interesting to me that the ability to utilize these qualities consistently is present in very case of those I consider to be great leaders.

The other aspect that Reggie discussed during the meeting was the fact that these are not business specific qualities, that they are universal and applicable in every aspect of life, from work, home, church, and every little league.

Being a great leader requires one to look those you are leading more than yourself. That is what these qualities encourage. The greatest leaders get the most discretionary effort from those they lead and ensure that those they lead get recognized for this effort. By making others they lead look great, they in turn look great too!