February 27, 2012
Know Your Team
To get bored in IT project management is to give up. No project is ever the same regardless of the technology being implemented. Every project requires some form of a project team which means people are involved. Even if you work with the same team over and over, there are always new inputs, influences and dynamics that make it a new situation requiring you to adapt as a project manager.
This is perhaps the most challenging and rewarding part of project management that applies regardless of the industry and technology. People’s lives are dynamic which means they are puzzles to be decoded on a regular basis throughout a project. Just when you think you’ve got it figured out, someone has a baby, gets a new boss, is heartbroken, or finds a fabulous new hobby. All of these things change the person’s priorities which means their interest and devotion to the project shifts and as project managers, we must respond accordingly to ensure that the project is successful.
It is important for me to get to know my project team members as people and not just as the resources on the project. I like to get to know them as individuals and understand what is going on with them personally and professionally. This provides me with a personal connection and a communication path to getting information regarding changes early in the process so as to better react in the event the changes impact the project. This sounds manipulative but it’s not. I am genuinely interested in the people on my projects. This is evident in that I keep in touch with most project team members long after projects have ended regardless of how tough the project was.
And this is the challenge…as project managers we must be genuine in our interest in the resources on our project. People can sense when you are only in it for the project or your own personal success. The good news is that the investment in the time to get to know the resources on the project and understand their motivations and obstacles, is invaluable for all parties involved. The team members feel heard and valued. The project manager gathers information to effectively manage the team. The project can move along towards success. And that’s what it’s all about in the end.
February 6, 2012
Learning From My Mistakes
I ran my second half marathon yesterday and based on my training, expected to come in at 2 hours and beat my first race time of 2:06. Training times supported this expectation as two weeks prior to the race, I ran 12.6 miles at a 9:09 pace. Reality didn’t match expectations and not only did I not reach my 2 hour goal, but I exceeded by first race time by 2 minutes. It was a very disappointing experience and one I don’t intend to repeat in my next races. Rather than looking at the experience as a complete failure (I held a personal pity party yesterday), I am choosing to learn from it. The success here was that I finished despite having to run and walk the last 5 miles of the race. What I learned was the following:
- Do not train beyond 10 miles prior to the race (I peaked too early)
- Do not play soccer the Thursday before the race (my legs were tired)
- Do not participate in any quad workout the week prior to the race (I had a softball coaching clinic with lots of knee bends the day before)
- Keep the mileage up until a week before the race, then taper (I tapered too early)
- Set my own pace and go with what is comfortable for me on that day, at that time
- Running a race alone is tough for me and requires super mental toughness that I need to train for
This is all valuable information and information I, personally, could only gain from failure. Other experienced runners provided me with some guidance that I ignored thinking it wouldn’t apply to me as a seasoned athlete. I may be a seasoned athlete but I am not a seasoned runner.
What is relevant here is that I made some fairly sizable tactical errors, still completed the race, and I plan to learn from the errors.
The same holds true with any projects I manage in that the results of a decision or series of decisions may not be as expected. The first goal is to recover from the errors and the second goal is to learn from the mistakes. I am constantly looking for ways to learn from previous experiences to improve processes and make things more efficient even if it was a total success. Actually, I apply this to all aspects of my life as accepting mediocrity and the status quo is not acceptable.
No project ever goes according to plan. Assumptions change. Resources change. Expectations change. Situations change. There will be mistakes, some more costly than others. The important thing is to learn from the mistakes and apply the newfound wisdom to the next situation so as to avoid a disappointing repeat performance.
February 2, 2012
Nail Down the Details Before Signing Any Agreements
Negotiating contracts with software vendors is always a challenge. The vendors won’t commit to resources until contracts are signed but without knowing the resources and their qualifications and availability, how do you know you will get what you want?
Vendors also want to defer detailed planning until after the agreements are signed. Once again this is at odds with best practices from a planning perspective. During the planning, a lot of details come to light that affect the final buying decision and overall timeline and budget. Signing before nailing down these details generally ends up being very costly from an expectation and overall resource perspective.
A number of years ago I was working for a biotech company and we were selecting an ERP system. A big name player was interested in breaking into the small-midsized life sciences market and saw our company as an opportunity to make this happen. Our budget wasn’t in line with their typical installs and they were touting a turnkey solution for life sciences. I was skeptical. They claimed the implementation and validation could be performed within our budget. After detailed planning and working through the resource assumptions, it became very clear that they were shifting the responsibility for significant documentation tasks to our team (which was limited) which resulted in the reduced consulting fees. Once we shifted the responsibility for those tasks back to their consulting team (to meet our timeline), the cost went through the roof and was no longer feasible. This was not a surprise to us. What was surprising was that they thought they would slip it by us.
In other cases, I’ve been brought into manage projects after agreements have been signed and quickly realize that my client made a series of assumptions (not documented) that were not aligned with what the vendor planned to deliver. This tends to put me in the awkward and uncomfortable position of renegotiating the contract without much leverage as my client has already committed. It often requires significant diplomacy on my part in that I have to demonstrate what was overlooked by them during the selection process. Since they tend to have to defend their decisions and actions internally (politics!) and the scope or budget or timeline changes once detailed planning is performed, it can get pretty hairy.
If you are able to work through the details before signing the agreement, a lot of this messiness can be avoided or minimized. I recommend performing the detailed planning prior to signing contracts, working with the vendor to create detailed statements of work to minimize surprises, and generating a project charter capturing the project elements. The project charter is an internal document but I generally have the vendor consultants read and sign as well in order to hold them accountable as members of the project team.
And one of thing greatest benefits of going through this process is that you can learn very quickly how committed the software vendor is to the success of your project and to your company. If a vendor is completely resistant to investing the time to generate a detailed statement of work based on detailed planning, this is a major red flag. I would seriously reconsider doing business with that particular vendor. Detailed planning sets everyone up for success.
Solutions2Projects, LLC 