Do you need to be a system expert to successfully implement it?

mythical_unicornI have often been asked to step into projects where the industry or software are unfamiliar to me. More times than not, the project team has been hesitant at first. A common sentiment towards project managers of many technical resources I’ve encountered is disdain. After a while, the team gets used to working with me and figures out how I can help. In many cases, I’ve changed the opinions of project managers for these technical resources. But why is that? What is it about my approach to managing data and software implementation projects that enables me to step into any project at almost any stage and help deliver results?

  • Willingness to learn – I am willing to learn. I know when to shut up & listen, take notes and ask later. I try to read the materials I’m provided, and if relevant, find external sources. I follow up with questions and try to make connections but acknowledging that I could have missed something.
  • General understanding of technology – I have a fairly good understanding of software development, database, data, workflow, process methodologies that gives me a foundation of understanding.
  • Resources – I’ve been lucky enough to have worked or socialized with a number of very smart people across a broad range of disciplines. I’m able to engage with my network on an as needed basis.
  • Know what you don’t know – It is imperative that I admit when I don’t know something. I need to engage with the right people at the right time, but yet recognize the dynamics of the situation and adapt accordingly.

I don’t think you do need to be a system expert to successfully manage an implementation project. I think you can develop enough of what you need to know to get involved to the extent you can. You’ll obviously need to adjust your level of engagement, and rely on your project team for the software expertise. You also need to know enough about the project and system to call bullshit when you need to.

Make sure to write the weekly status report!

TPS_Report_MEME It really doesn’t matter how often you communicate with the project team, don’t forgo the weekly status report. I can, and do often think of several reasons why I “can’t” get to it, but having that status report has several key benefits.

 

  1. Aligns everyone to progress and issues – Many times progress and issues can get lost in the smaller, tactical project team. However, a software implementation can be quite a big investment and therefore impacts people outside the immediate project team. The weekly status report provides that source for where we are now, and where we are going.
  2. Ensures broader audience keeps your project in mind – While lots of people may need or want to keep the pulse on your software implementation project, other priorities can get in the way. By distributing your weekly status report you are managing multiple layers of stakeholders, and ensuring that your project isn’t forgotten.
  3. Credibility – building on the theme of the last blog post, status reports build credibility. If done in a way that gives an honest account of where the project is, regardless of whether it is going well or where there are opportunities for improvement, you are building credibility to you as a project manager and your organization (vendor, department, etc) as a partner.

I generally am on the side of streamlining process, and reducing administrative nonsense. In the case of status reports, they really are a critical tool in keeping everyone in the loop about where you are. If the stakeholders are new to you as a project manager, you may need to redirect people to your status reports, but generally, people jump on the bandwagon and like the more formal approach.

 

Building credibility one step at a time

bricklayerIt doesn’t matter if this is the first project with the customer, or the whether you have done tons of projects with them, each new project provides an opportunity to further build credibility (or lose it). From a project management perspective there are several tools that can be used to help facilitate this. The 4 critical ones I’ll dive into today are:

  • Requirements
  • Action Items
  • Issues log
  • Validation Sign Off

Requirements

I talked extensively in the last 3 blog posts about scope, which lays out the tasks that need to get accomplished. Requirements take this a step further, defining the business rules, and needed or wanted criteria. These are the nuances and details upon which the customer is benchmarking your solution. As a project manager, make sure you have these clearly documented, and understood by the entire project team. If there are questions or concerns, raise them early and often. If the requirements change, capture the details of the change and the decision (who & when).

Action items

Action items is a simple list of follow ups for the team. This are usually pre-requisites to accomplishing scope and requirements. This is less about a task list for the project development team, but more of a way to capture dependencies. Sallie can’t start working on X, until Tom provides Y. The resultant action item is Tom to provide Sallie with Y before she can begin working on X. These action items should be reviewed during the regular status call.

Issue log

An issue log captures open issues. Ideally, the development team could act as a perfect proxy for the business users and a project wouldn’t be required to go through user acceptance testing “UAT.” Unfortunately, the reality is that no matter how close a development team is to the business problem, nuances and use cases get missed. The issue log is the means to captures issues identified by project QA or business UAT. It tracks who, what, when, where & how.

  1. who reported the issue?
  2. what is the issue?
  3. when did this issue happen?
  4. where in the system is the issue?
  5. how can the project team replicate it?

Validation Sign Off

It is imperative in a project to receive validation from the business users. It is also important to capture who did the validation and any special circumstances that may have existed. In many projects, anomalies or unexpected results are identified but they don’t change the implementation. They merely need to be acknowledged by all the project development team and the business stakeholders and documented for future reference. These details can be useful in training and rollout as well.

Each of these tools are helping build credibility with the customer. They see that you are hearing them, acknowledging them and documenting the findings each step of the way. At no point should anyone be blindsided by the details of requirements, dependent action items, open issues or signed off results. These are fundamental to project management, and what a project manager needs to do to be successful.

Project plans are your source of truth

It’s been a while since I last wrote about project plans, calling them living, breathing documents. As part of the recent series digging into the critical components of scope and estimates, project plans are the next logical discussion point. Project plans are the manifestation of the scope and estimates. It comes in the form of gantt charts, excel work breakdown structures, calendars, etc.

The project plan, in whatever form, is a combination of tasks (scope), timelines (schedule ), resources and cost (sometimes). They can be high-level or very detailed. They should show dependencies among tasks. However, I would caution you to make them too detailed, as they aren’t set in stone, and making them complicated means it can be painful to update. Give yourself and your project team enough information to see what needs to happen, when it will happen, and discussion points for scope changes, issues, etc.

Most project managers have their preferred tool. My preference is the simplest tool for the project team. In my cases, this is usually a work-breakdown chart in excel. Excel is something that most business professionals know how to use. You also have flexibility in how much detail you provide and it’s fairly easy to update.

Most important is for the project manager to be regularly reviewing and updating the project plan. Always accurately represent where you are in the project. This is something that you should be sending out to key stakeholders on a weekly, or semi-weekly basis. It really does become the point of reference for discussions. Stakeholders may not read it, but you can use it to guide discussions, and point to it as the single source of truth. This is key.

Trust that your scope will change

The Project Management Book of Knowledge defines scope as the project boundaries. I prefer this definition on TechTarget:

Project scope is the part of project planning that involves determining and documenting a list of specific project goals, deliverables, tasks, costs and deadlines.

From a practical project management perspective, what does this really mean? Who gets to define this? How do you manage? Let’s delve into the details of a scope.

A very simple evolution of a project is sales > implementation > support. Scope is relevant in each of these phases, however it may not mean the same thing to the stakeholders key to each phase. A company agrees to invest money in a project to solve a business problem. A salesperson has convinced the company that they have the solution. Here’s the first step of the process where scope can diverge. Can the corporate decision maker speak for all the business stakeholders? Do they really understand the details of the business problem that needs to be solved for each type of user? And how about the sales person? Do they really understand the software? Do they understand the business problems it can solve? Are more technical sales engineers involved in the sales process?

That simple example involving just the corporate decision maker and the sales person is indicative of how scope can rapidly become a problem in a project.

Scope must be managed throughout the entire project. 

Over the course of my career, I have had different levels of involvement in the sales process. Some I was involved from the first demo/sales call with the customer, others I help with preparing estimates and potential timelines, others I inherit after the contract is signed and others I inherit long after the implementation. It doesn’t matter at what point I become involved in a project, my first action is to receive a copy of all project artifacts. And yes, I do read that contract. I want and need to know what was committed.

Unfortunately, I’m not done there. I take the details I can find in the contract and communicate those out as often as I can. If this is a large project with multiple business teams, I will review the scope with each team. This is the opportunity for your customer, and more specifically the business users, to vocalize their agreement (or not). Either is fine, but it is imperative to align expectations. If there is disagreement, it is the responsibility of the project manager to sound the alarm to the corporate decision makers, and the services and sales organizations. Misaligned scope results in 1) unhappy customers, 2) stalemate of customer and company or 3) mutual agreement to realign scope. Note: The scope doesn’t necessarily have to be immediately changed. It is sufficient for the new work to be phased in after the initial scope implementation.

This is definitely a rinse and repeat process. Business are changing on a daily business, and implementing data and software projects means your environment is constantly changing. Time doesn’t stand still during implementation projects. This means new inquiries and requests come up constantly. Each time, you need to figure out how it fits into the work you are already doing. Some requests can be easily accommodated, but others need a deliberate approach to determine how it impacts existing goals, timelines, budgets, and overall commitments.

Do not fear the scope. The scope is your friend. It provides guiding principles for the work you are doing, and the goals you are accomplishing.


https://www.tamingdata.com/wp-content/uploads/2010/07/tree-swing-project-management-large.png

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

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.