Monthly Archives: December 2015

Use Cases & Technological Investment: The Technology Chicken & Egg?

by

In traditional manufacturing, it’s unheard of to purchase production grade equipment without knowing exactly what it will be used for, and more importantly how the significant cost will be recuperated. However, I have seen it first hand that this isn’t always the case with technological investments. It is not uncommon to make a significant investment in a software or hardware solution without fully understanding the business use case.

Courtesy of iterated-reality.com

Courtesy of iterated-reality.com

A September 2015 blog post by Jarvis on Technological Trends that Impress VCs emphasizes leveraging your business use case to make purchasing decisions. Similar themes include not going extravagant until necessary, improvising as you scale, and ultimately not making a purchasing decision merely because the technology is the best, but rather choose the best solution for your business.

A Workspace blog post “Investing in new technology – right for my business“, written by Mark Sharman, discusses some of these same points. Mark raises the concern of being carried away by all the technology bells and whistles, so strongly recommends having a business use case or cost/benefit analysis to fall back on. Additionally, the “real cost of the investment” needs to be fully recognized, inclusive of delays and opportunity costs of not doing something else. That said, Mark reminded us that surviving in business requires keeping pace with change, but thriving in business requires leading the change.

This effectively highlights the conundrum of use cases versus technology investment. If you make the investment to stay on top of changes in technology, will the use cases come? Or if you define the use cases, will you be leading the pack but putting yourself at risk?

Example 1

In one example I’ve seen, the CTO had implemented a massive initiative to move everything to the cloud. At the time, I oversaw highly critical, back office processes. While we had been in the process of reinventing our systems, it didn’t make a lot of sense for us to move into the cloud. It would have added extra layers and complexity, and moved us away from our data sources. However, the implication of not complying to the blanket initiative were large enough that I chose to define a solution where we would be able to move components to the cloud. After I left my position, a former employee of mine, who was still involved, asked why I had designed the system for the cloud. To him, it didn’t make any sense. I agreed, but explained the nature of the political decision I reacted too.

Moral of the story: Just because we can, doesn’t mean we should.

Example 2

In another example, I was working with a company to implement a very complex software solution. They made significant investment in this solution, and worked closely with us during the development and validation phases of the project. There were two project phases that each took 5-6 months to complete. After the implementation was complete, we didn’t hear anything else about it for another ~6 months. At this time, the company asked for a in-depth, technical and business training working through the business requirements through to the technical implementation. During that training, I was told that the team was still working on the use cases for how they wanted to leverage the solution.

It seemed to me that the significant investment in capital and time would have encouraged the need for a business use case before implementation, but that wasn’t the case. Should the company have made this investment without the use case? They were at the cutting edge of this solution, and were able to influence the process by taking a very hands-on approach.

Moral of the story: Sometimes it’s better to be first and influence the solution, than worry about exactly how you are going to use it.

I was talking to my mentor and friend, Dave Shuman, yesterday about this. He challenged that some of the newer, trending technologies lend themselves to investment first, then defining the use cases. The low barriers to entry from a cost and implementation perspective allows for that buy first, define later approach. Lean Startup development methodologies also lend themselves to building in incremental blocks, then iterating until you find the “right” product fit for your customer.

Final Thoughts

So whether you define your use case first, or whether you invest in technology first, you do need to figure out that sweet spot to getting to your return on investment. We all know how well it turns out if you spend all your money and have nothing to show for it.

3 Considerations When Managing Globally Diverse Project Teams

by

Global project teams happen more often than not these days making it no longer feasible to get everyone in a room to facilitate a project. As a Project Manager & leader for both global team members and global customer teams, I’ve experienced the added complexity of this on my projects.

A LiquidPlanner blog post by Tim Clark from October 2013 “7 Tips for Managing a Global Project Teams” highlights time zones, cultural, religious, and sociological differences. Mr. Clark also recommends staying on top of advances in software solutions to simplify the process.

Global Teams

My Experience with Global Teams

Inc. published “5 Tips to Manage a Team Across Multiple Time Zones” by Will Yakowicz in July 2014, which also had very applicable information. Mr. Yakowicz reminded us that we can’t work 24 hours/7 days a week, emphasizing a consistent schedule. He also encouraged us to leverage the latest technology, invest in airfare to facilitate team cohesion while also recognizing that we must be extra aware of those people who aren’t sitting in the same room as us.

In my experience, there are a few additional key considerations for successfully managing global teams.

  • Be Flexible – As the project manager, it was my responsible to facilitate the project. Some things do just get lost in translation over email, and it’s necessary to have a phone or video session. Unfortunately, it’s not all about me, therefore it can’t be all about my time zone. I often had calls in the early morning or late night to coordinate with Europe (EMEA) or Asia (APAC) as required.
  • Be Available – When you have remote teams, it is imperative for each team member to be more communicative than would be required if everyone was in the same place. I can’t hover at someone’s cubicle when they are based in Ireland, but I can make myself as available as possible, as well as encourage each of my team members to do the same, on any mediums used by the respective regions.
  •  Diligently Break Down Barriers – Communication is hard. It’s even harder when you’ve never met a person, other than via email or phone. More often than not, when you are driven to a phone call it’s to resolve an issue. I encourage you to take the time to introduce yourself and chat. By learning the personality traits, and what drives your team, you will be better able to motivate them.

Managing global teams is difficult. The pace of project delivery, technological advances and life adds to the complexity. However, it is the new normal. We’ll need to step up our game to learn to do it well.

Professional Services Leadership – 3 Reasons to Engage your Project Team with your Clients

by

There has been a long running discussion in professional service organizations about whether the technical project team members should be engaged with clients, or whether they should be sheltered from clients often under the guise of allowing them to focus on their task list. In my experience as a Project Manager and Customer Success Manager, I’ve found that allowing them to engage with clients directly streamlined project communication, and expedited the “right” development.

An April 2012 Inc article “The New Rules of Customer Engagement” by Wendy Lea outlines the new customer engagement paradigm. The focus has shifted away from single, often isolated touch-points to a much more integrated, customer-focused, results-driven experience. This particular article is geared towards engagement in social media, it drives home the point that customer service is no longer seen as just part of the sales process. Every conversation that happens, in any venue must be driven toward customer resolution.

https://s3.amazonaws.com/webmobi/Development/websitepics/customer.jpg

Web Mobi Customer picture

A October 2014 Survey Monkey blog post discusses 5 crucial reasons to engage your customer service and product teams as a means to deliver consistently great customer service. It argues that product project teams don’t spend enough time with marketing or customer service to fully understand customer issues and sentiments.

Overall, I think we can agree that being fully engaged with our customers, including fully understanding customer issues and sentiments, is imperative to our business success.  Even further, it is a given that our organization needs to be fully engaged across internal teams. I argue that the technical project teams also need to engage with customers directly. Three critical reasons include:

  1. It streamlines customer communication – When a technical resource needs to make decisions based on business requirements, it can be significantly easier to communicate a question directly to the customer. Critical details often get lost in translation when the technical resource communicates to a project manager, who then translates it to the business user.
  2. It simplifies the project management role – By allowing the direct communication, the requirement for the project manager to be technical becomes minimized. The PM should still understand the technology, but their focus becomes more of a facilitator and a remover of obstacles.
  3. It more closely aligns the customer to the technical team – When the technical project team engages with the customer, and visa versa, each begins to see behind the curtain. This allows each side to more fully appreciate the challenges and opportunities that exist. If the customer never experiences the technical process, or the technical team never experiences the business requirements, you lose the epiphany moments that come from truly solving the customer’s problem rather than more superficial symptoms.

I have seen great success with having my technical teams engage with customers directly. It becomes my role to manage the scope, prioritize the follow ups and generally keep everything on track. I step in to facilitate conversation or remove barriers to success, but don’t get in the way of progress. I challenge each of you to review your engagement model and figure out how to incorporate customer-technical resource communication.

Professional Services Organizations: Do your Project Managers Create Work or Remove Obstacles?

by

I’ve had several conversations lately with software developers or business management regarding project managers, and whether they create work or remove obstacles. As a project manager myself, I’ve felt that removing obstacles and allowing resources to focus on the tasks at hand is one of my top priorities.

In researching this issue, I found a September 2005 article by Scott Berkun “The Art of Project Management: How to Make Things Happen” that highlights that the ability for people to move project forward (AKA remove obstacles) is a skill that some people have, but others do not. Berkun proposes that this skill comes down to knowing how to be a catalyst in many situations, while also having the courage to do it. Additionally, projects move forward more when: prioritization occurs; “no” is accepted and appreciated; open & honest communication occurs; the critical path is known and the PM is relentless & savvy.

PM Technical Skill to Execution Matrix

PM Technical Skill to Execution Matrix

A more recent article published March 16, 2015 in MITSloan Management Review by Alexander Laufer, Edward Hoffman, Jeffrey Russell & W. Scott Cameron “What Successful Project Managers Do” emphasizes the organizational responsibility required to allow project managers to be flexible. This research article states that project managers need to: develop collaboration; integrate planning & review with learning; prevent major disruptions and maintain forward momentum. This ultimately results in a more fluid, adaptive project.

As projects have become significantly more technical in nature, the divide between project managers who create work or remove obstacles has become more pronounced. Technical implementation projects push this even further. As project leaders, we need to recognize the impact of technical skill and the too many active projects on ability to manage a project to its completion. There are 4 combinations on the technical skill to execution matrix:

  • Technical but Overworked – These project managers have the skill, but are not capable of removing obstacles because there are too many other projects on her plate.
  • Technical & Actionable – These are the technical project managers that are able to remove obstacles for their team. Often these resources get overlooked by the project team as they are seen as just doing their job.
  • Non-Technical & Actionable – These resources tend to be PMI certified so know the mechanics of managing a project, are able to remove obstacles without needing to fully understand the technical pieces.
  • Non-Technical & Overworked – These project managers also tend to be PMI certified so know the mechanics, but are overworked so they can’t focus on removing obstacles. Ultimately these pieces get pushed to project resources.

As a technical project manager, I have some bias about which quadrant the rockstars reside. However, there are some strong non-technical project managers who are able to successfully complete projects. This requires management support and a level of organizational prioritization that is really difficult.

Project Managers: 3 Tips for Managing Project Schedule When Client Expectations Don’t Match Implementation Timelines

by

There are often misalignments in the available time for a project implementation and the full range of work that needs to occur. As a technical project manager, I have managed this scenario many times as a result of optimistic sales schedules, distorted expectations of the custom software implementation (versus installation of out of the box software) or a variety of other reasons.

Kenneth Darter wrote in a in March 3, 2014 blog post on ProjectManagement.com that there are 3 Methods to Managing Customer Expectations: Optimistic, Realist and Pessimistic. Different organizational groups lean towards different methods. An optimistic approach can result in customer & team frustration when hiccups or schedule slippage occurs, while pessimistic approaches sometimes breed mistrust as the estimates are so padded that nobody believes them. Realism in project estimation requires significant a solid understanding of the team players, the work that needs to happen & client expectations.

PM_constraintshttps://www.projectsmart.co.uk/understanding-the-project-management-triple-constraint.php

As Duncan Haughey pointed out in his December 19, 2011 post on Project Smart, it is often said that there is a 3-way constraint In all projects between cost, time and scope, with quality assumed. This has recently evolved to a 4-way diamond of cost, time, scope, quality, with customer expectations as the foundation. Without understanding the customer expectations, it will be incredibly difficult to you make the right decisions regarding cost, time, scope or quality.

Regardless of your primary method for setting schedules, you will always need to take into consideration cost, time, scope, quality, and most importantly customer expectations.

  1. Communicate the Facts – In reviewing the list of work before a weekend migration project, it became apparent that there were more machine hours of work to migrate some historical data than existed in the weekend of the deployment. Armed with the facts, I was able to talk the client into reducing the scope of the historical data migration for the deployment weekend and plan for remaining work after the fact.
  2. Discover the Business Motivation – During a data integration project with aggressive timelines, a client requested 2 weeks for internal validation. After initial pushback, it became apparent that the issue wasn’t our work, the client had data quality concerns from the source and needed to determine the impact to the business. We were able to tweak our approach to the project to help mitigate some of the concerns.
  3. Be Vigilant – As a project manager it is imperative to keep your pulse on the project. When snags occur (and they will), you need to communicate loudly and often to ensure the project team and the client understand what happened, why it happened and how it’s being resolved.

At the heart of every project are the client expectations. While there is an inherent quality you should push your project team towards, cost, scope & time will all radiant around the expectations and adjust as required.

favoritepicDagny is currently Managing Director at Digital Ambit, a consulting company focused on helping you with your data and software integration needs. Dagny has almost 20 years of experience in project delivery & customer success of software implementation projects.