From the monthly archives:

August 2007

Organizational Alignment and Project Success

by Eric D. Brown on August 30, 2007

Organization Alignment seems like one of those ‘touchy feely’ things that most technical folks would rather not discuss but it’s actually quite relevant to success in todays technology and project driven organizations.

Organizational alignment is the practice of aligning an organization’s strategy and culture. In other words, organizational alignment helps to ensure that ‘what gets done’ is in line with ‘how things get done’ and vice versa. For a more detailed description of organizational alignment, take a look at the article on Organizational Alignment on Vanguard Consulting’s website.

As mentioned, Organizational Alignment is the act (or art?) of aligning strategy and culture. The field of strategic planning and organizational strategy is a very well researched and fairly well covered in academia (and blogosphere) so I won’t go into the ’strategy’ aspect but I will cover the ‘culture’ side here.What does organizational alignment have to do with project success? In my opinion, everything.

For a project to be successful, an organization must have its strategic goals aligned with its cultural values…and projects must also be aligned with the organizations’ culture and strategy. Consider the following brief example (paraphrased from Vanguard Consulting’s website):

Assume that the goal of your organization is to create a flexible service delivery model to allow you to be flexible for your clients. You’d want to make sure that the organization is aligned to meet these goals by having flexibility as a core value. You wouldn’t want to implement a ‘command and control’ structure that requires everyone to get approval before acting. The command and control structure would completely counteract the stated goal of flexibility for your clients.

The cultural aspect of organizational alignment covers ‘how things get done’ (while the strategic aspect covers ‘what gets done’). The ‘how’ covers the values, behaviors and processes for getting things done, which are things that can be addressed across the organization using various methods, such as the implementation of a Project Management Office (PMO).

Many organizations have implemented PMO’s to standardize project management methodologies, align projects with corporate strategy and act as a central point of management for all things projects. The majority of these PMO’s usually don’t address the values and behaviors across the organization. In fact, most definitions of a PMO only describe the use of a PMO to standardize project processes and align projects with strategy but values are usually overlooked.

A PMO is a good thing for most organizations but its doesn’t go far enough to ensure alignment. Standardizing project methodologies can be a good thing but standardization doesn’t go far enough to address the issues of values and behaviors. The PMO, by definition, isn’t setup to address values and behaviors but could easily be converted into an office to help align values, behaviors and process and perhaps it could be renamed the ‘Project & Alignment Office’ (PAO).

So….after all of that (and my creating the PAO!), how do we ensure project success by organizational alignment? We don’t…you can never ‘ensure success’…but we can help set projects on the path towards success by working to align the ‘how’ with the ‘what’ and the ‘why’.

Look for more to come on organizational alignment and projects…and maybe even more on the newly created PAO :)

[tags] Project Management, organization, Strategy, Projects, Project, Strategic Planning, culture [/tags]

Zemanta Pixie
Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 2 comments }

Business Dev: Small actions = big consequences

by Eric D. Brown on August 25, 2007

While out at dinner one evening this week I happened to be following a large SUV with an advertisement for a local insurance agent painted on it. I’d seen the SUV around town and had thought about calling to get a quote since my insurance was coming up for renewal…looks like their marketing strategy might be paying off.

As luck would have it, this SUV was going to the same restaurant that we were and pulled in ahead of us. The parking lot was very full so and it took us a while to find a parking place in the far corner of the lot. As we came around the corner of the restaurant we saw the Insurance agents SUV parked in a handicapped parking spot.

At first, I didn’t think anything of it and assumed that the person was handicapped and had the requisite plates and/or placard. As I got closer to the SUV, I realized that they didn’t have either and that the neither of the two people getting out appeared handicapped in any way. I recognized the driver of the vehicle as the insurance agent painted onto the side of the SUV and decided to test him a bit.

I introduced myself to him…he was a pleasant man and we made small talk while we waited to be seated. I pointed out his SUV and we talked about the ‘cool’ painted ad on the vehicle. I then mentioned to him in a surprised voice that he forgot to put his handicapped placard.

His response was a laugh as he said that he wasn’t handicapped and didn’t know anyone who was. He laughed again while describing their search for a parking spot close to the front door, and since they couldn’t find one, they took the handicapped spot that nobody ever uses.

I smiled and said that we had parked in the far corner of the parking lot and felt like we had walked a mile. I then asked if he thought about what would happen if someone did need to use the spot and he just laughed it off and said ‘they can park somewhere else’.

I decided that he had failed my little test and told him so. I told him that prior to seeing his disrespect for the handicapped that I wouldn’t be calling to get a quote for my insurance and that he should be ashamed of himself.

His response to that was : “That’s ok…I wouldn’t want your business anyway. I can’t get by just fine without 1 or 2 car insurance policies.” I smiled at him and mentioned that I had been thinking about calling for quotes on 2 car policies, 1 home policy, 1 business policy, life insurance, and some investments that I had been wanting to move to a new agent.

Needless to say, I never called him after that.

Moral of the story:

Consider how the smallest action (like parking your car while eating out) can effect your image. The small things to you may be a big thing to someone else. And for goodness sake…if you have your picture painted on your vehicle, try not to act like a fool while driving…you will probably turn off some of your clients.

[tags] Selling, Business Development [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 6 comments }

Agile or Waterfall…does it matter?

by Eric D. Brown on August 24, 2007

First off…let me answer the question: Does it matter if I use Agile or Waterfall methodologies in my project? My opinion is no…it doesn’t matter…but there are a few caveats to that answer. Read on.

In the software development world, there’s been a debate raging for quite a few years about the ‘best’ way to manage software development projects. The two main sides in this debate are Agile and Waterfall and both sides have strengths and weaknesses and work better in some situations than others.

There are people that believe Agile works better for smaller projects and Waterfall works better for more complex projects….but I’ve come to the conclusions that they can both work equally well in any situation with the right people in place and the right organizational alignment. There is one caveat though: I’ve never heard of Agile methods being used in very large scale complex projects (construction, defense industry, etc) and don’t believe the agile models scale that well to projects of that scale but I’d love to be proven wrong.

Some will argue that Agile doesn’t scale well to projects that require more than a few programmers, but I think that has more to do with how Agile has been used in the past on larger projects than any real fault of Agile methods…of course, the previously mentioned caveat still applies.

Others will argue that the more traditional ‘waterfall’ method fails for smaller projects that require a more flexible and speedier approach to developing software. Again, it may not be the waterfall method at fault but the way in which the organization approaches the project that causes the failure.

My personal experience shows that Agile works very well in small projects that require fast development schedules. As I mentioned in a previous case study titled “Agile Project Management & Product Strategy“, Agile methods allowed the development team to release a working product within 3 months with a final release within 6 months…compare that with the 12 month Waterfall development plan that had previously been developed.

The case study mentioned above shows a positive result of the power of agile methods in software….but it isn’t the only way that we could have reached these results. I’ve gone back and looked at the development plan and after careful thought and reflection, similar results could have been achieved with a waterfall type development plan by removing some of the ‘fluff’ that was added to the plan.

After many discussions with ‘experts’ in the field and hearing “agile is best’ or ‘agile is just a fad…stick with waterfall’ and seeing projects fail or succeed using either of these methods, I realized there isn’t any methodology that is ‘best’ to use to manage projects and engagements.

It’s not necessarily the methodology used that causes failure or success in projects, it’s the way in which the organization is aligned that creates project success or failure. I truly believe that an organization can can choose whatever methodology they want to manage a project, but without proper organizational alignment and empowerment of the project managers and team members, the project most likely not succeed.

In other words: It isn’t the process or methodology used…it is the people involved that will help a project succeed. Of course, processes help, but without good people and an organization that helps those people succeed, any project management methodology will most likely fail.

I’m planning another article in the next few days that dives deeper into how organizational alignment affects project success….check back soon for more.

[tags] Project Management, organization, Agile, Projects, Agile Project Management, people [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 7 comments }

The best hiring advice I’ve heard

by Eric D. Brown on August 23, 2007

Chapter 13 of “What were they thinking” by Jeffrey Pfeffer has some excellent advice for hiring managers….the chapter, titled ‘Resumes Don’t Tell” has a subtitle that is the best piece of hiring advice I’ve heard in a long time:

Pick people for what they can do, not what they may have done.

I wish more hiring managers would heed this advice.

Of course, a person’s past accomplishments are an excellent way of telling you what that person has done and what they may be capable of doing, they aren’t a guarantee that the candidate will reach the same level of accomplishment while in your organization.

As I’ve mentioned before in previous posts, hiring is one of the most critical functions an organization can undertake and shouldn’t be taken lightly. A resume can tell you a lot about a persons credentials and past but very little about who the person really is and how they work, their ethics and the things that they are most passionate about.

[tags] hiring, human resources [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 1 comment }

Simplenomics: Carl Hubbell teachs a salesman to sell

by Eric D. Brown on August 22, 2007

I’d like to point out Mike Sigers’ post titled “Can a Salesman Learn to Pitch?” on his Simplenomics blog.

In this post, Mike recounts a story of a salesman who learned how to sell by studying baseball great Carl Hubbell, the inventor of the screwball. The main reason for my wanting to point this post out is to show how someone can strengthen their sales abilities but studying clients/prospects before trying to sell to them. Of course, every good salesperson should do that but many don’t.

The other reason, and a slightly selfish reason, is that I love to see Carl Hubbell’s name. You see…I’m from the same small town (Meeker OK) that Carl grew up in and have always known about ‘King Carl’ and his great career as a pitcher. His appearance in the 1934 All Star game is still legendary…he struck out five of the best hitters of the era in succession: Babe Ruth, Lou Gehrig, Jimmie Foxx, Al Simmons and Joe Cronin.

If you ever visit Meeker and drive through the town on Highway 62 (the east/west road), you’ll see City Hall and the “Carl Hubbell Museum“. Nothing fancy here…just a one story metal building that houses the police, volunteer fire, city hall and a small area with all of Carl Hubbell’s memorabilia that he and his family donated. Note: If you drive through town on Highway 18 (the north/south road), you’ll miss most everything…except for the blinking stoplight and the corner gas station. Yes…the town is that small…the last census showed 996 people in town.

Long live King Carl and the Screwball.

[tags] Carl Hubbell, Screwball, King Carl, Meeker, Oklahoma [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 0 comments }

Is Great Customer Service Enough?

by Eric D. Brown on August 20, 2007

Over the weekend, my wife and I went out to a restaurant for dinner to celebrate her birthday. This particular restaurant is very well known in town and is fairly pricey and is a place we’ve been to before. On the previous visit, the service was excellent and my wife’s dinner was great but mine was just OK…I chalked it up to the cut of meat I ordered and enjoyed the evening with my wife.

When my wife mentioned going out to dinner to this restaurant for her birthday, I was a little hesitant as I remembered the meal from our last visit, but her meal had been excellent so we tried again. Again the service was exemplary…our waiter was perfect and was always there when we needed something and never there when we were trying to have a conversation. Leading up to the meal, the bread and salads were OK and the glass of wine I ordered (Hartford Zinfandel) was excellent so I was hopeful that the meal would be much better this time.

I was wrong. My wife ordered exactly the same thing she had last time and I ordered the Filet Mignon. In my book, it’s extremely hard to mess up a good filet but they found a way. The meat was tender but the ‘flavor’ was horrible….it tasted like it had been soaked in mesquite flavoring for a few days. I don’t mind mesquite but there should only be a hint of mesquite on a steak.

The kicker for me was my wife’s meal. Her meal was terrible too….she ordered King Crab legs (this place is known for crab) and somehow they messed this up to with some type of seasoning that overpowered the food and made it the worst crab she (and I) have ever had.

We mentioned this to the manager and his comment was “I’m sorry that you didn’t like your dinner…how about a gift certificate for 2 for your next meal”. The manager’s intention was good…but why would we come back? The food was horrible.

I can’t say enough good things about the service at this restaurant but the food was terrible and I would never recommend this place to anyone else. This just goes to show you that great service isn’t enough to be successful…you need a great product too.

NOTE: Hat tip to Kent Blumberg for his post titled “Shouldn’t miss customer service details” for reminding me that I wanted to post this story. His post is absolutely spot on… customer service is in the details. The ’small’ details can go a long way to create a great customer service experience…these ’small’ details are something that the restaurant definitely understands…its the ‘big’ details (like the food) that they got wrong.

[tags] Customer Service [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 4 comments }

Blog Changes

by Eric D. Brown on August 16, 2007

I will be making a few minor changes to this blog. The domain name is changing and I am thinking of changing the name of the blog…I have setup a poll for your thoughts on the name change.

Domain Name Change

After trying for quite a few years, I was able to finally get my name as my domain…ericbrown.com now belongs to me….finally! The blog will be moving domains from its current domain (http://ericbrownpm.com) to http://ericbrown.com sometime within the next month. The move should be seamless to everyone with the current domain and RSS Feeds redirected to the new domain. I will post a quick note once the domain move has occurred.

Blog Name Change

I also plan a minor adjustment to the title of this blog and would welcome any feedback. I am torn between the two following titles (please provide your feedback via the poll below):

  1. “Aligning Technology, Strategy and Execution”.
  2. “Aligning Technology, Strategy, People and Projects”

I like option #2 because that really is what I have focused on and what I want to focus on in the future on this blog and in my career. I’ve setup a poll (see below)…feel free to vote for your favorite.

Name Change Poll

[poll=2]

[tags] domain name change, blog name change [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 7 comments }

Billy McCafferty over at Devlicio.us just published a short blog post titled “Introduction to Scrum and Agile Development” that contains some excellent resources for people interested in learning more about Agile Software Development. He provides links to some great Agile & Lean resources as well as a zip file that contains a few of his presentations that he recently gave.

For those of you who aren’t developers (like me), Billy provides a presentation geared toward managers (see the Zip file he has on his blog post). This Management presentation does a great job of providing an overview of the agile mindset and Agile methods and is one of the best overviews of Agile Methods and “why go agile” descriptions I’ve seen.

It seems Billy has the same take on Agile as I do….he likes to approach Agile using a combination of Scrum, XP and Lean methods. Good stuff and worth the read.

[tags] information technology, Project Management, Agile, Scrum, XP, Lean [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 0 comments }

Customer Service Defined

by Eric D. Brown on August 14, 2007

If you ever want to know what Customer Service truly is and is not, let your Air Conditioner fail and start calling AC Repair companies.

Our AC went out yesterday. Of course, yesterday was the hottest day of the year here in Dallas. Thankfully, it stopped working in the evening instead of during the heat of the day.

My first step was to try to ’solve the problem’ but I quickly realized that my AC problem solving skills ended after trying the ‘is it on’ and ‘is the breaker on’ steps.

I then called the company that installed the system to ask for a service call and after waiting on hold for 5 minutes and being asked a ton of questions in a very mechanical manner, I was told that the first available technician could be at my home on Wednesday.

Normally, that would be OK, but with the 2 chinchillas that we have, we needed something faster than that. Chinchillas need cool temparatures…anything above 75 is deadly.

My next call was to a local AC company, but since it was 9PM, I received nothing but voicemail…ditto for the other 2 companies. I then decided to try one more person who I had heard good things about. Dwight Stewart, owner of Dwight’s Heating and Air in Sachse TX, answered the phone on the first ring. Imagine my surprise to actually hear a live person answer the phone.

I explained the situation to Dwight. He walked me through some basic troubleshooting steps and asked some questions. After the troubleshooting didn’t work, he said he would be at my house the next day and would call me first thing in the morning to let me know when he would be there.

I received a call at 8:21AM from Dwight telling me he’d try to make it to my house around mid-day today and would call when he was about 30 minutes out. I then received a call at ~ 11:45AM telling me he was about 30 minutes out. He showed up to the house at ~12:15PM.

30 minutes later, the AC is fixed (the capacitor was busted) and all is well. Many thanks to Dwight and his excellent customer service.

More organizations and service professionals need to learn from Dwight’s service.

[tags] Customer Service [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 2 comments }

Successful Technology Implementations

by Eric D. Brown on August 14, 2007

I recently turned a six month consulting project into a 1 month project…and I couldn’t be happier. The client saved ~$1.5 million and they were able to turn around ‘failed’ software implementation.

Why I’m telling this story

Before I get into the back-story, I want to share the reasons for telling the story. It isn’t to talk about how I’m a great consultant or how well I work with clients. I’m sharing this to provide an insight into how technology implementations can easily be deemed a “failure” and how easy it sometimes is to turn that failure into a success story.

Technology can be used to help an organization succeed…but only if implemented in a seamless manner. The ideal implementation would be to allow all processes to work in the exact same manner after the technology is implemented as before.

Of course, there are very rarely ideal implementations, but you can minimize the effect that new technology has on an organization during planning phases.

When poorly planned, technology implementations can wreak havoc within an organization. If technology is thrown into an organization without any thought to that organization’s processes and operating model, there will be a lot of headaches for the users of that technology.

Implementing technology isn’t an easy, step-by-step process that follows a predetermined task list. There must be a considerable amount of thought put into how the technology will integrate into the organization and how that organization can best use the technology. Without this type of planning, technology implementations will fail.

The “back-story”

The project supposed to be approximately 6 months of assisting a client with implementing a new HR software package. The new package was replacing another package that they had been trying to implement and use for more than a year.

The CIO who contacted me told me that they had gone through 3 different consulting companies while attempting to implement the original product and didn’t feel as though they had been successful.

The HR software package was originally implemented by the services arm of the software vendor. The implementation plan was their “standard” plan that had been used with many organizations with varying levels of success and failure. With this implementation, the software vendor didn’t provide any customizations (perhaps they weren’t asked to) and after the implementation was complete, the end-users didn’t feel that they could use the software to do their jobs.

After the software vendor failed, my client then hired a large consulting firm to come in and “redesign the HR system and processes” to make changes to the organization to fit the HR software package. This firm proceeded to fail miserably due to not understanding their client’s needs & expectations. My client then hired another consulting company and realized quickly that they would have the same problems.

After the fiasco with the previous implementations & consultants, the CIO contacted me and asked if I’d be interested in coming in to discuss their problems and help point them in the right direction. I’m not an expert in HR software at all…but I do understand technology and the need to adapt technology to meet business objectives….and apparently, that is exactly what they needed.

The company was on the verge of buying a completely new HR software package because they were tired of dealing with the old and thought the new system would make everything OK (this is rarely the case but it happens all the time).

The CIO asked me to come in and help select the vendor and help oversee the implementation to ensure that all requirements were met. I visited with the client, took a look at the original implementation plans and started talking with some of the key stakeholders. I quickly realized that the plans for the new software package were no different than the original plans.

The plans called for the organization to change their processes to match the new software rather than the software being implemented in such a way as to accompany the processes in place. This is usually a step in the wrong direction because you are asking your organization to change very rapidly with a new software package AND new processes.

I asked the CIO for 2 weeks to study the current system and see if there was a way to salvage it. He agreed and the HR team and I set about looking for a way to save the company ~$1.5 million in software licensing and implementation fees (on top of the almost $2 million already spent on the previous package and implementations).

I spent a few days with the HR team and realized that the old software, whose implementation had been deemed a failure, would work quite well for them if a few modifications were made to allow them to follow their original processes.

After a few days of discussions and thought, the HR team and I sat down with the CIO and shared our plan with him. I told him that the original implementation was handled fairly well but the original idea for the use of the new software was flawed. Instead of forcing the software and process changes on the organization, as the original plan called for, they should have implemented the new software and customized it to fit the needs of the HR team.

A new plan was then presented that called for the already implemented HR software package to be customized to match the requirements of the HR team. This work could be performed best by the software vendor instead of farming it out to another consulting firm.

Once the customizations were complete, the vendor would then train the HR staff on using the tool and spend a few more weeks working with the team to ensure they were able to use the software in the manner in which they required.

The plan was approved by the CIO and the software vendor. The vendor, who was happy to be back in the client’s good graces, agreed to split the cost of the customizations and to provide training and additional consulting services at a discounted rate.

Conclusion

I didn’t do anything special with this client. I think the biggest value I provided was an independent set of ‘eyes’ to look at the problem and evaluate the issues.

Instead of a spending six months on a project managing a large scale implementation of a new HR system, the project ended in 4 weeks. The client saved a considerable amount of money (~$1.5 million) while regaining the use of an underutilized software package that had been considered a failure. The software vendor was able to repair a relationship with a client, which seems to be something the vendor likes as they’ve called me to help them with a few other projects.

Successful technology implementations require a little common sense, a little thinking and some consideration of how the technology will affect the business. Project planning and management tools are also require, but if the upfront thinking hasn’t been done, there project may start out on the wrong foot.

[tags] Human Resources, Technology, information technology, technology implementation, HR Software [/tags]

Zemanta Pixie
Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook