Category Archives: Project Management

6 Considerations for Making System Migrations Successful

by

Every business makes a system migration decision. The frequency of these decisions has increased significantly, as the improvements to technology are delivered more quickly. Unfortunately, migrations tend to take much longer than everyone wants or thinks. My experience has shown that the following considerations need to be understood and carefully managed to have a successful migration.

  • Why are you migrating?
  • Are there hard dates that apply to the project?
  • How broad is the data or processes you are migrating?
  • How are you controlling the transformation (of data or processes)?
  • How and when are you validating?
  • What are the plans for cutover, training and UAT?

Why are you migrating?

There are always multiple reasons for making a migration decision. Some may be technical like obsolete hardware or degrading software. Other times it may come as result of cost. Regardless of the reason, it is imperative that you also provide business users a reason for the move. This migration will be an inconvenience and they will need to adapt to a new system. You should not do anything that impedes their ability to advocate for the new system. It helps if you can showcase some quick wins by delivering some new business value.

Are there any hard dates that apply to the project?

While this might seem like an obvious question to be asking, it makes a huge difference in project planning. With legacy applications, it is very difficult to plan for every unknown. There tend to be layers of configurations, application upgrades, and varying techniques for implementation and execution (read “spaghetti code”). While all projects should have timelines and deadlines, many times you can build a buffer window in to account for the uncertainty. Ideally, you are planning for future use not just blindly implementing a new system the way it was before. Now is the time to proceed with a fresh set of eyes while still maintaining the insights garnered previously.

How broad is the data or processes you are migrating?

This question tends to raise interesting responses. For all practical purposes, most business users use a finite set of data (year-to-day, 1, 2, 5 years). However, if you pointedly ask a business user what the minimum amount of data they could live with, inevitably the answer will be all of it.  This generally conflicts with how much IT really wants to store or with practical wisdom of data management. Over time, the system has changed, therefore the underlying data has changed.There is a real possibility that early data is of questionable quality and will add no real value for ongoing business use. It may also add some complexities to the implementation process as well. This is also wisdom for most process migrations. Unless you can demonstrate business value of leveraging less data or fewer processes, business users may be wary of the new system.

How are you controlling the transformation?

As mentioned previously, it is recommended to look at a migration from a fresh perspective. Often, this will introduce some requirements to transform the data or process. The application of business rules or assumptions must be fully documented. Additionally, any resultant changes in data or processes identified during the validation stage should be related to those business rules. Make sure the business users embrace the these decisions. If they do not, it will be challenging to get them to engage later in the implementation, or post implementation where critical eyes are determining whether this project is a success.

How and when are you validating?

There are quite a few different steps in the validation process that must occur in a migration. First, there are the basics of making sure your system is implemented and configured to your requirements. More critical is validating that the business use cases return the expected results. Your implementation team should be validating at each step of the way to ensure that issues are quickly identified and resolved.

Validation must occur using methods or interfaces the business users will use. There are general concerns and uncertainty about new systems and being able to provide validated results using agreed upon business processes can go a long way to appease them. Some anomalies are legitimate and they must be fully explained and documented. All sets of tests need to be documented, reviewed during training and UAT and made available to stakeholders in formal documentation or on an internal intranet.

What are the plans for cutover, training and UAT?

Business users need to feel comfortable fulfilling their most basic business needs. If there are nuances or differences on how to accomplish these or in basic assumptions around them, these should be highlighted accordingly. Next, it is helpful for the business users to learn skills that can deliver new business value fairly quickly post-implementation. The goals are to reassure business users that they can still deliver the value they did with the old system, but also that they have new functionality that allows them to deliver new value quickly. This may be as simple as making old value propositions better, faster or more robust.

During this time, the implementation team must quickly respond to questions, issues or concerns. These are the most basic interactions the business users are going to have and will start laying the groundwork for the trust that is required for an implementation to be considered successful. The ultimate goal is for the initial users to fully engage and become advocates across the organization. If these users fulfilled that role with the old system, it will be detrimental to success if that is lost. If these users were not advocates before, it is imperative to win them over.

Project Coordination vs. Project Management

by

For as long as I can remember, I have described myself as a project manager. I found it was the simplest way to explain what I did. In reality, I have been a Sybase database administrator (DBA), systems analyst, software team lead, business process manager, implementation manager and most recently, a customer success manager. At the end of the day, I get s**t done. I found that the term “project manager” was the simplest way for people to grasp what I do.

I have started to wonder whether I’m using the right term. As I compare my methodology to how others are managing projects, I wonder if “project manager” may not be inclusive enough. Additionally, the response I get from resources involved in my projects often is one of pleasant surprise. Their prior experiences or preconceived notions of what a “project manager” is has left them jaded and unimpressed.

A few years back I was brought into an organization by a mentor and former boss to help alleviate his workload so he could focus on raising money for the organization. Prior to my entrance into the organization, everyone did everything for their customers. There were no project managers. This resulted in project delays and the curse of constantly switching gears to focus on the biggest fire. At first there was subtle push back and doubt as to what value I was bringing to the table. Out of necessity and as a result of the influence of my mentor, the project resources started engaging me on the basics – timelines, status, meetings, etc. As I got more involved and took on more responsibility (i.e. owning the documentation, managing the communication, pursuing the missing information) those same resources started to come around to me as a “project manager.” I believe they view me as the exception rather than the rule.

More recently, I overheard a conversation regarding a project where technical resources were responsible for writing status reports and updating the project team. This very much confused me as I have always felt that this function was a core responsibility of the project manager. After probing a bit, I learned that the project manager did not understand the technical solution and therefore was unable to provide descriptive enough project statuses. I understand that the project manager is in an oversight role and will rarely understand every detail of how a technical resource plans to implement, but I don’t understand how they are going to oversee every piece of the project if they don’t understand individual components.

These are just 2 anecdotes that make me ponder whether I misunderstand what a project manager is or incorrectly associate this term to what I do. A good project manager requires equal parts operational understanding, technical skill and project coordination.

PM

Operational Understanding: To manage a project effectively, it is imperative to understand how that project fits into the big picture.

  • How does it impact the business unit?
  • What motivates the project owner?
  • How will it impact the project stakeholders?

If I don’t understand that the goal of the project is to significantly reduce costs or improve efficiencies in order to prevent layoffs, I may not see or understand the anxiety of the stakeholders or the project owner. I may also not know the right way to motivate the team or get to the root cause of disagreements.

Technical Skill: Furthermore, it is crucial to have an active part in the technical conversation.

  • How do you step in to test or troubleshoot?
  • How do you mitigate disagreements between technical resources?
  • How do you translate between technical resources and the business owners?

Technical skill allows me to get my hands dirty when required. It is the reason that I can play “cardboard batman” to work through complicated project issues. It also allows me to step in and mitigate disagreements between technical resources, and pursuasively communicate decision “whys.”

Project Coordination: Lastly, it is critical to know what goes into running a project.

  • How do you estimate a project task?
  • How do you allocate resources and make sure milestones are met?

This is the nitty gritty of running the project. It’s the logistics – status meetings and reports, milestones and gantt charts, task estimation, etc. These are the basics you need to know. Unfortunately it is not enough to make sure project successful. Only by combining the basics of project coordination with technical skill and operational understanding can you truly get s**t done.

Defining Project or Customer Prioritization Models

by

I’ve come to appreciate the difficulty of project prioritization.  Historically, my teams only ever really had internal customers.  In some ways that makes the decision easy – you focus on the biggest revenue opportunities or impacts first.  Operational issues came first, with development coming second.  This problem becomes exasperated when you are in a consulting situation where there are multiple customers, with multiple customer teams and often, conflicting priorities.

At the end of the day, people want to do the right thing.  Ultimately what happens when you combine a lack of project prioritization with people who are striving to “do right by the customer” is time spent on non-priority tasks or employee burnout trying to meet everyone’s needs.  Neither one of these outcomes is optimal for teams.

In our personal lives, we make prioritization decisions everyday. Most often we put things we need to do (i.e. eat, take care of children, work to support family) before other things (i.e. sleep, exercise). This may not be the best long-term decision, but it is the best decision we can make at the time it comes up. The nature of business complicates this problem significantly as ever customer needs to be treated with respect. Each customers’ problems are the most important to them. If every organization had infinite resources, dedicated teams could exist to service each customer.

Unfortunately, resources are limited and you have to make trade-offs. People do understand this. They may not like it, but it ultimately comes down to how well you set and manage those expectations. An organization should evaluate their core values and align their prioritization methodology to it. While large and small customers should not necessarily be treated the same, it is important to make sure that you have a strategy for handling both sets of customers. This exercise must be re-evaluated on a regular basis. Some common prioritization considerations include: customer size, project duration, complexity, strategic project nature.

Customer Size: This really comes down to revenue. Your largest customers bring the most money to the organization and therefore need to be kept happy. Sometimes, some creative solutions might need to be introduced. This might be dedicating a team to customers over a particular size, or providing on call services to these select. As I mentioned before, the downside of this is you can’t do this at the expense of all your other customers. They won’t be ignored.

Project duration: If you can focus on a project, get it done quickly and make a big impact, there is value to making this a priority. There is a risk to constantly pulling resources in and out of new projects. You might want to consider a roaming “quick-hit” resource squad to rotate through these types of projects. It can be a great way for more junior resources to learn and grow, continuously being introduced to new case studies. Duration can also negatively impact prioritization as covered by complexity.

Complexity: Complexity is an interesting consideration. Who defines it and how does this impact how you use your resources? A project might be considered complex if it is something you have never done before; or it has quite a few moving pieces and is expected to take a really long time to complete. Additional complexities might have to do with hard deadlines outside your control. One way to minimize the impact of complexity on prioritization is to separate a complex project into more manageable mini projects. You can then prioritize based on your other factors. There may be a few cases where you will need to evaluate project complexity as a factor. This may increase prioritization of the project in order to meet strict deadlines, or it may reduce prioritization of the project given the state of other business and projects.

Strategic Project Nature: We all are aware of opportunities that come along and introduce us to a new market, technology or methodology. These can come from the large customer looking to push the limits, or a small customer willing to take a gamble on us. The upside of these types of projects can be significant, but if things go wrong the project could impact project duration, revenue, and resource allocation.

Once you have your prioritization factors, you need to decide how to weigh them. Giving each consideration equal weighting does simplify the process, but that may not work given your customer and project mix. You might be in the middle of a pivot and need to put greater emphasis on the strategic project nature than you do on customer size. You also need to determine your scale for assigning value for each prioritization factor to each customer or project. This can be as simple as rank order for the number of projects or customers. It could also be a simple 1-n scale, with n equal to 5 or even the number of factors you are using. For both weight and scale, make a decision and move forward.

This is an evolving process, so define a few prioritization factors as a starting point. Once you choose your weight and scale, you have a solid prioritization methodology. Apply this to your customers and projects. You should start seeing the benefits within a few weeks. Projects should finish and your ability to set and meet expectations of your customers should improve. Feedback from your customers will deliver the biggest set of data points. Adjust accordingly.

 

Why do you need a cardboard batman?

by

I am not a software developer.  I do have some training as a database administrator, most of experience is in managing projects and teams for highly technical initiatives.  This ranges from shopping cart and credit card integration for an e-commerce site in the early stages of the Internet; the creation of automated renewal subscription processes; billing systems; customer portals; complex billing processes for publicly traded companies and legacy to SAAS migration of critical business software.  I raise my experience here as I want to talk about the principle used in software development called “rubber duck problem solving”, but which I have been using and calling cardboard batman for my entire career.

“Cardboard Batman” refers to the act of clearly articulating a technical problem and in the process solving it, without any help from the person you talked to (real or fake).  I have to thank my husband, Carson, for introducing me to this concept. I met my husband 20 years ago at a small, e-commerce startup.  He was the programmer and I was the project manager.  At the pinnacle of the dot com bubble, our days, nights and weekends were often filled with work towards an aggressive deadline.  This often meant that Carson would be sustaining himself on mountain dew and pizza and I was constantly asking “are you done yet? is it ready for me to test?”

Inevitably an issue would arise late at night with no seemingly easy solution.  After Carson would spend some period of time trying unsuccessfully to debug his code, he would call me over to explain what he was doing. This usually involved walking me through software code in the language du jour and trying to step me through the problem – both what customer problem he was trying to solve and what issue he was running into.  This is where my lack of programming skills became an asset.  In translating between the customer problem and the software code, more often than not, the issue would become obvious.

Over the years, I have incorporated this methodology into my project and product management.  It forces you to step back and rethink the problem you are trying to solve and the current solution.  In many cases, it has exposed a different, better way of doing something.  It has also allowed me to manage highly technical developers, database and system administrators, without necessarily having that classical training.

So, Do you have a cardboard batman (or rubber duck) readily available?

While we call it something different, the cardboard batman method is real and sound.  You can find more at this blog, youtube, wikipedia and even urban dictionary.

What color are the glasses of your perception?

by

Miriam-Webster defines perception as the way you think about someone or something; the way that you notice or understand something using one of your senses.  I have had several recent conversation related to perception and having been thinking how that plays into business relationships and context.  

The first was how you are perceived by others and whether you need to change some of those perceptions to move forward in life.  I was asked to come up with 3-5 perceptions that other people have about me.  I used “cold/unfriendly” as one of those perceptions.  In actuality, I’m cautious when getting to know people.  It takes me a little while to get used to new people and open up.  Once you get to know me, you find I’m willing to talk about anything and I will be incredibly loyal.  I can see how that can be perceived as cold or unfriendly.  Ultimately, I am aware of this perception, but have chosen that caution and loyalty in the beginning works well for me right now.

The second related to how different stakeholders perceived a project status.  Some felt that nothing had been done and interest was faltering by the new users.  While there had been some issues in the project implementation that caused some delays, the implementation had actually progressed and lots of work was being done to resolve the open issues.  While both sides had responsibility for the project state, the perception of the situations were very different.

Perception comes into play every day, in every personal or professional situation.  While you aren’t necessarily going to be able to change every perception, you do need to be conscious about how others are going to perceive a situation.  Each one will be tinted by their individuals experiences.  Keep in mind that all perceptions are rooted in grains of truth.  Use this to guide your responses and actions when there are differences in perceptions.

 

 

What I learned on my run about working through tough situations

by

We all have all been in situations where things aren’t going your way.  This could simply be a single thing that sets you off, but more often one becomes two becomes three.  When this occurs it’s very hard to see the light at the end of the tunnel.  Everything is shrouded in a veil of negativity with no end in sight.

During these times, it is important to find one grain of positivity.  It could be as simple as acknowledging the beautiful day outside, or buying yourself a bouquet of flowers, or snuggling in the corner with a hot cup of tea and a good book.  These grains of light produce the energy for the next one.

I had this epiphany the other day while I was on my run.  I’m not a runner, but sometimes when it’s been a tough week and I feel I need to push myself and get some exercise, I will run.  I don’t run races and generally prefer to run alone.  I can comfortably run between 2 and 5 miles, and at the end of the day, I know I can walk myself home.  My coping mechanism for making it through my runs involves looking for the next immediate milestone.  This is usually a tree, street sign, fence post, etc.  I always have enough energy to make it to that next marker and once you string lots of markers together, you make it home.

I’m convinced that I can apply this to those situations where I sense myself getting frustrated after multiple frustrating things have piled up.  I just need to find that one moment of sanity and comfort and convince myself that I can make it to the next one.  This challenge is short lived  and can be overcome, just as the next one can and the next one. Before I know it, I’ve pushed through to a better, stronger place.

Lessons Learned from Planning a Job Fair with a Volunteer Army

by

I’ve spent the last five months planning a job fair using primarily a committee of volunteers.  While event planning is done every day by event planners, and marketing folks, this was ultimately a 500 person event spanning 3 hours, plus another 2 for setup.  I have had small roles in larger conference planning for prior companies, but have never had this as primary responsibility.  I learned a lot in the process.

1.  Be organized – The number one lesson to planning a successful event is organization.  This seems obvious, but can be challenging when dealing with volunteers.  Often times, documentation from prior years resides in people’s heads rather than on paper.  Take the time to lay out what you need to accomplish, with goals, rough timelines and fill in the rest as you go along.

2.  Use all of your resources – I had a primary committee who worked on job fair planning, but I was not shy in reaching out to other committees that had a shared interest, or could help us.  This event is a core benefit for sponsors so it made sense to really engage and integrate a sponsorship committee liaison.  We had several conversations with communications about what they will do and how we needed to target our audiences.  Additionally, there were reasons we had to rely on our main office for support.  It was a collaborative effort, but make sure you don’t lose sight of the end goal.  You can’t single-handedly accomplish a successful event on this scale without taking people up on their offers, and asking for the assistance you.

3.  Try new things – I felt my role as leader of the event planning team was to generate new ideas and expand our reach to make this the most successful we could.  This meant being willing to identify new exhibitor prospects from county lists of honored companies, reaching out to small growing organizations who might not previously engaged with the organization, and incorporating more social media marketing.   Each of these ideas were successful in varying degrees, but we wouldn’t have known that without testing the ideas.

4.  Have a backup plan – Whenever new ideas are introduced it is imperative to start thinking in terms of backup plans.  For us this meant being creative about where support service organizations would be positioned within the job fair; inviting wait listed companies to attend the event to network, but encouraging them to check-in to see if any tables opened up (2 did and were immediately filled as a result of this contingency).

5.  Over communicate – It is imperative to make sure you are over-communicating.  There isn’t the luxury of patiently waiting for something to happen.  Lay the information out for everyone involved to see and know and meticulous track your progress along the way.  This allows you to adjust as ideas positively or negatively impact your target outcome.

6.  Shameless promotion – As the leader of the planning committee it is important for you to be seen promoting your event.  Even if your network is small, your committee and those involved need to see you putting the event out there.  This will encourage them to follow in your footsteps. This should be done at all stages and for all audiences of the event.

7.  You can’t please everyone – All you can do is make sure everyone is well informed about what’s happening and you are doing your best to make sure both exhibitors and attendees are as prepared as they can be.  You can not control exhibitors participation – from providing details for job seekers so they can research in advance; presenting their company with engaging displays, table decorations or give aways; or actively engaging job seekers.  You can merely provide the tools for their success, but at the end of the day there is only so much you can control.

I had a really good experience.  I had a great team who helped guide me through the process, and staid on top of their own tasks.  We had 190 recruiters and 300 job seekers, with few hiccups and very positive feedback.

Scrum and the Art of the Obstacle Course

by

What do you need to get through a complicated, every changing software development project and a Tough Mudder obstacle course?  A great team is a good starting point.

This concept isn’t new.  Ken Schwaber and Mike Beedle talk about it in “Agile Software Development with Scrum.”  They liken building software to running an obstacle course.  “Agility, flexibility and adaptability are required to succeed (p 99).”  They argue that following a set plan won’t get you to the finish line.  It is the art of balancing everyone’s skillsets, collaborating at each step, and openly communicating that allows for software development success.  Schwaber and Beedle further push the point by emphasizing that the team needs to self-organize and lead the efforts.  A manager, project owner, product owner, or other stakeholders can only assist the natural order of the team.

This resonated pretty well against everything that I heard about the Tough Mudder, and similar obstacle course races.  The Tough Mudder started with a 30-something fit men demographic who could probably “brute-force” their way through many of the obstacles.  That demographic has evolved to include 80-somethings and more fun focused teams,  In all cases, it has become less about “brute-force” and more about collaborating on the best solution.  Competitors have challenged Tough Mudder obstacle creators by using obstacles in unanticipated ways.  Like the agile team, a coach is going to be able to provide minimal support during the actual obstacle course.  It is his/her job to prepare the team for the challenge and eliminate hurdles prior to show-time.

Having managed multiple software development projects, this approach seems pretty intuitive.  Each team member knows their strengths, weaknesses and skillsets.  They will also be first to see the challenges.  Therefore, it makes sense for the team to to manage themselves, with a coach to nudge them in the right direction.  This approach requires an incredible amount of trust between team members.  Once this is established there should be a cohesive and collaborative group to overcome the typical challenges in software development.