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 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.
January 31, 2012
IT Deviations: Tool for Improving Overall Performance
I am a firm believer in documenting deviations from performance expectations for IT systems. This includes functional and procedural errors, both system and human. Documenting deviations provides data for better management and control over IT systems. The process for capturing and managing IT deviations should be simple to be most effective as we know most IT folks do not like cumbersome documentation tasks especially if they think they will be penalized as part of the process (which should not be the case, ever!).
A basic deviation has the following elements:
- Deviation description
- Date(s) of occurrence
- Categorization for tracking purposes (planned, unplanned)
- How it was discovered and by whom
- Investigation into source of deviation
- Recommended resolution or actions to be taken
- Approvals of investigation and recommended resolution
- Documented action taken to resolve issue
- Approval of action taken
Deviation examples include:
- Backup failures
- Failure to follow documented procedures
- Unexpected system behaviors
- Unplanned outages
By tracking and trending the deviations, you can see if there are recurring issues and answer the following questions to improve data integrity and reliability.
- Is additional training required?
- Should work instructions be developed or be more detailed?
- Is there a technical issue that needs to be addressed due to a repeated failure?
- Is there a configuration issue that needs to be addressed?
- Should the issues be addressed with a vendor?
- Does the system need to be replaced?
IT personnel and business system owners gain visibility into issues and can track patterns if deviations are documented. It is too easy to forget when something happened (let alone if it happened at all) and how it was resolved. We have too much to keep track of these days. Deviations are often seen as something that is bad rather than as a useful tool to gather information to improve overall performance. For those of us in IT that like data, deviations should be seen as an effective tool to gather data to improve overall system performance.
January 25, 2012
Staying Connected
During a project it is very easy for me to focus on the tasks and forget about focusing on the people (other than to make sure they know what tasks they are to be working on). I assume that everyone is working toward the same endpoint and that completing tasks is the most important thing. I have to remind myself that part of my job is to stay connected with the people and make sure they are feeling the love. It is easier to stay connected than to have to reconnect after a period of neglect.
This means getting up, walking around, getting on the phone, and giving team members and stakeholders personal attention. In a formal team setting, they don’t always want to openly discuss issues related or unrelated to the project that could indirectly or directly impact the project. Taking the time to give them an opportunity to feel heard is vital to the success of the project.
Sometimes the information or feedback is difficult to hear (which may be why I sometimes avoid it) but to be effective, I need to set aside my personal insecurities and do what’s right for the team members, stakeholders, project, and client. I often learn things that may not be pertinent at the time but can be useful later or when pieced together with other pieces of information, begin to form the answer to a problem we might be encountering or better yet, provide us with an opportunity that wouldn’t otherwise be made obvious to me.
This is helpful personally as well. While at a coffee shop this morning, I bumped into a friend I hadn’t seen in a while. She’s on a board with my husband and mentioned a meeting tonight that I wasn’t aware of. This prompted me to text my husband to confirm that I need to be in home with the kids. The bonus here was that I got to reconnect with a friend and, as an extrovert, replenish some energy that’s been lacking a bit lately. She also shared with me some information about some mutual friends and community projects that I am storing for future reference (all of it good). I had to look away from my computer long enough to have the chat but it was worth it.
As a goal oriented person it is so very easy to focus on ticking things off the to-do list leaving others to their own devices. This also leaves others to their own agendas which may not match up with the goals and objectives for the project. Making the communication a to-do list item (a high priority one at that) is critical for project managers. The people are the keys to the success of the project regardless of the number of tasks completed and staying connected keeps the people connected to project.
January 19, 2012
Carrot or Stick
What is the best way to motivate project team members? The short answer is that it depends. It depends on the individual and as project managers it is incumbent upon us to find out what works for each person and tailor for each.
We must get to know the team members and understand what makes them tick. This takes time that may not appear to be a value-add at the beginning, but it is certainly an investment for later in the project when things really need to get done. Finding the lever that will get each person moving in the right direction toward the collective goal, helps to eliminate some of the bumps on the road to project success.
This also means that incentives and rewards need to be built into the project and project budget. While it would be nice to assume that project team members are intrinsically motivated to do the ‘right thing’, the ‘right thing’ is different for each person and doesn’t necessarily align with the project goals.
The team can be rewarded or recognized collectively but individual agendas need to be identified in order to increase the likelihood for success. The rewards do not need to be costly and they sometimes don’t cost anything. For some, recognition is the best reward. Others require cash. And others, flexibility to work on project tasks at 2 AM.
Think about what motivates you. What does it take to get you motivated especially when you’ve been assigned to a project that takes you out of your normal routine and comfort zone. What would motivate you to work more effectively? What information or tools do you need or want? What rewards do you like? Are you motivated by fear or money or recognition?
The first step is recognizing that getting your team members motivated to work effectively towards the project goals and objectives cannot be achieved with a one-size-fits-all approach. The most important and hardest step is taking the time to find the lever that will make each team member a more productive member of the team but it’s worth the effort.
January 18, 2012
Outsourcing to Save Our Sanity
Recently I realized that I will not be the one to teach my children how to drive. I realized this when my 10 year old was driving the golf cart while we played golf the other day. It was quite stressful and we were only going 5 miles per hour and no other carts or pedestrians were in sight to run into or over. Apparently my husband had already given thought to this and was in total agreement. We have both realized that some things are better left to professionals to save our sanity, increase likelihood of success and reduce likelihood of bloodshed.
This got me thinking about my clients and the essential skill sets they need to have on site in their staff versus those that are needed on a periodic basis. Most of my clients are only able to cover the basics like helpdesk, network, and if they are lucky, database. Once enterprise or business specific systems are in place, a business analyst is pretty critical. But IT project management? The expertise is only really necessary when they are implementing a new system or upgrading and existing one. This is a function that can be outsourced to experienced professionals.
When hiring an external IT project manager for a small company (less than 300 people) in the life sciences industry, compliance experience is key. Without this experience, the projects can be seriously under planned as validation may not be considered. Validation is a process that begins at the beginning with requirements definition and vendor selection and goes through system retirement. Validation is not just documented testing and can add significant time to a project depending on system complexity and risk assessment.
Another key element is experience working in small organizations where a project manager has to get his or her hands dirty. We don’t have the luxury of simply leading and guiding others as resources are generally limited and timelines short. Therefore, IT project managers in this segment need to step in and act as business analysts, validation resources, and trainers in some cases.
Outsourcing IT project management makes sense as projects, by their very definition, have a defined beginning and end. Once the project is over, it can be closed out and transitioned to on site personnel for ongoing support and your company does not need to retain additional headcount when the project is over. If done properly, the project-specific knowledge gained by the IT project manager during the project, is transferred to the on site support personnel before the project is closed out.
As for drivers’ education, oursourcing makes sense for us personally. Hopefully the training will be a short-term project beginning with a spin around the block with everyone coming back alive with no bloodshed and ending with a driver’s license. At this point, as with system projects, once the project ends, or in case of my kids with their driver’s licenses, the real fun and headaches truly begin.
January 17, 2012
Change is Hard
My dad often said that if it weren’t for the clients and employees, his job would be perfect. The same could be held true with regards to project management. The system implementation from a technical perspective isn’t hard; it’s managing the people and expectations that is most difficult.
We all know change is hard. We also know it is necessary to grow and move forward. Why do some of us resist it even when we know intellectually it is good for us?
I know that from my project experience employees are afraid. In their minds are a series of questions, especially if they haven’t gone through the process before. Will I still have a job? Will I be able to do my job? What if someone finds out I don’t know what I am doing? What if someone wants more from me than I can do or that I want to do? I am comfortable with my discomfort; why do I need to change anything?
I find that getting affected people (team members, employees, stakeholders) to talk about these issues (externalize rather than internalize) acts as a release valve and reduces the fright associated with the unknown. We also discuss the benefits associated with the change and acknowledge the discomfort associated with the uncertainty. This doesn’t happen just once and is an ongoing process throughout the project and through the adoption phase after Go Live. If users don’t use the system and continue to follow old practices, the implementation cannot be considered a success.
As project managers we are always managing…people, tasks, expectations, constraints. How we help the people in the organization adjust to the change is a major factor in determining the success of the project.
Solutions2Projects, LLC 