Experiencing Marketing

Experiencing Marketing

Shifting Focus

by Bryan Peterson on 04/18/14

I'm going to be making a change of sorts.  Up until now, I've been focusing mainly on writing about project and program management.  Lately, I begun shifting more toward writing about digital marketing and all things related: email marketing, social media, blogging, customer engagement, content marketing, etc.  While I've been working as a project manager, over the last few years I've been managing projects within the digital marketing space.  As such, I've begun consulting, advising, and focusing my efforts on working with marketers on a variety of aspects of digital marketing.

I've decided that my blog will reflect this now as well.  Renamed 'Experiencing Marketing', I will be writing on various aspects of digital marketing, customer engagement, authenticity, personalization, social media, and few things in between.  As you may have noticed, my twitter feed has reflected this shift for a while now.

I don't claim to be a full on expert nor to have all of the answers.  I am passionate about it and eagerly working to increase my knowledge and understanding each day.  I'll be writing and sharing on topics I'm seeing in the space, trending areas of interest, experiences I have and insights I uncover.  I may also incorporate some quest posts on the blog.  My thoughts, opinions, musings, and whatever else are my own.  

I'll keep my project management content available here on the site as I've curated some helpful stuff and the blogs I've linked to continue to produce very valuable content.  Feel free to let me know if you have any comments, concerns or questions. I hope you'll find my knowledge and experiences interesting and useful.

An Adaptive and Evolving Project Execution Process

by Bryan Peterson on 11/17/11

It's been quite a while a since my last update in which I described my foray into Agile.  I shared my process of being introduced to Agile, how I came to take the leap and try it, as well as my search through different Agile methodologies to find one that fit my high volume, high velocity, short term, non-software development project environment.  I am happy to report that we've had great success.  Our team has been able to work vastly more efficiently on a larger number of projects.  We've become much more scalable enabling us to take on and complete more project work without increasing team members or our work hours.  In fact, we've seen a decrease in the amount of time we're putting in and on occasion when we do work late it's more of a choice than necessity.  Most notably, we've become much more predictable.  Hitting our project delivery dates is critical to our business and slippage can be a major issue.  With our new process, we've been able to hit our initial target dates within about 10%-12%.  This is an acceptable margin, especially when considering that much of our project slippage was due to things outside of our direct control like client readiness or other delays on the client side. We've also been able to identify areas in which we can make up time to accelerate when necessary and effectively balance a portfolio of a large number of active projects.  It's changed the way we think and approach projects.

I've gotten a lot of feedback asking for a description of our process that's is ultimately a hybrid of Agile processes including Scrum, Commitment Based Project Management, Kanban, and a little additional innovation thrown in.  Here's a description of what we're doing.

Project planning is based on weekly iterations.  Each week, we have a lengthy planning session in which we have a retrospective of the previous week, share lessons learned, call out praise worthy performances and actions, discuss areas for improvement, as well plan the next week's committed deliverables.

All projects are divided into seven phases (Planning & Initiation, Configuration, Design, Technical Integration, Quality Assurance, Delivery, and Launch) that are represented by milestones in the project schedule.  Each milestone has an associated set of deliverables for completion of that milestone represented by to-dos.  The next upcoming project milestone is that project's horizon.  Our projects have a lot of similarity between them making and we're able to have some repeatability with our delivery process.  We've also defined the process at a high enough level that it can easily apply to most of our projects and variations can be easily accounted for.

Deliverables from each project's horizon are placed in the backlog noting the client, phase, deliverable, priority, date needed by (milestone) and any comments.  Each deliverable is then weighted with an order of magnitude estimate.  Estimates are a .5,1,2, or 3, indicating the deliverable counting as half, 1, 2, or 3, deliverables.  Estimating is done via blind voting by the entire team and requires consensus.  Discrepancies in votes are discussed until each estimate is agreed to. 

During our weekly project planning sessions, the team decides which deliverables in the backlog are to be moved into that week's list of commitments.  The sum of all of the deliverables' weighted estimates will provide the total number of deliverables committed (ie. a deliverable with a weighting of 2 counts as two deliverables).  The team has established a work-in-progress limit that defines the total number of deliverables that can be committed to for that period.  The WIP Limit is set such that the team can target 90%-100% completion of deliverables each week.  You can think of this as our work-in-progress limit is represented by a certain number of slots to be filled.  The weighting gives us a slightly more than rough order of magnitude indicating if a deliverable is taking up one, two, three, or a half slot.

The committed deliverables are then be broken down into sub-deliverables or tasks, if needed.  Originally, we used post-it notes placed on our rolling white-board to track the deliverables in that iteration.  The owner of the deliverable would simply pull down the post-it note when complete.  As the team began to take ownership of the process, they decided to replace the post-it notes with tickets in our ticketing system.  The tickets have labels indicating it as a project commitment and associated deliverable.  This keeps it separate from the actual work tickets until work on that deliverable begins.  These tickets are initially unassigned, thereby creating a queue of tickets representing that week's commitments.  As tickets are worked on, they are assigned to the appropriate  owner.  As deliverables are completed, they are marked as such in the iteration tracking sheet we've created on on an internal wiki page.  A deliverable is considered completed when all work has been performed to the established quality criteria. 

This left me with an interesting problem.  I loved my white-board.  I loved having a sort of physical manifestation of our project work that we could reference throughout the day.  It served as a reminder of all of the work that we had to do and gave us a sense of accomplishment when we pulled things off the board as we completed them.  Now that our work was moving digital, I wouldn't be able to use the white-board in the same way.  I definitely didn't want to to try and find a use for it just for the same of having it to gather around during our daily stand-ups and planning meetings.  Then it hit me.  One of key areas I was looking to address with a transition to Agile was the schedule.  As project manager, I was responsible for managing the project schedule.  However, I wanted to get the team more involved with creating the schedule.  I wanted more of their input on the deliverable dates and for the team to validate and update the schedule as the project progressed.  I wanted to get consensus and commitment to our deliverable dates.  If the team's committed dates didn't match the dates of the business or the customer, it was my job to work with the team to get them aligned.  If expectations needed to be reset with the business stakeholders or customer, I would do that.  After all, we were now communicating dates we were realistic committing to and not guesses or dates we "hope we'll hit".

Each project is represented on the white-board with each phase's target dates.  The team is able to accurately predict and commit to the due date of the horizon milestone with a high degree of certainty.  The remainder dates of the scheduled milestones, though not committed, can be extrapolated, estimated, and communicated to the customer accordingly.  This all is also done during our weekly planning meetings. 

Each day, the entire team participates in a daily stand up meeting.  These meetings include the entire team and generally around 10 minutes and absolutely no longer than 15 minutes.  The purpose of these Stand Up meetings will be for each person to answer three questions:

                1. WHAT DID I DO YESTERDAY?

                2. WHAT WILL I DO TODAY?


The team also validate each project's schedule by agreeing that each project horizon is either realistic and something the team can still commit to or that it needs to be adjusted.  Early warnings of deliverables that will miss their commitment date or slip beyond the targeted iteration is to be expected.  The team is highly encouraged to bring up these early warnings as soon as they are known and no one will be punished for doing so.  This is one of the most important tenets of our project process.  The people who are doing the work are the ones contributing to the planing and reporting on that work.  No one is ever punished for speaking up about potential needed adjustments to the schedule.  I encourage people to tell me "We're not going to complete this by that date".  What I don't want to hear is "We didn't get this done".

Overall, the team has reacted very well to the new process.  There was an adjustment period.  We learned to communicate better and more effectively.  We eventually found our cadence and are now very effecient, predicatble, and productive because of our adaptive and ever evolving project execution process.

Processing Into Agile

by Bryan Peterson on 06/21/11

I am crossing over into Agile.  Well, at least we're going to try it.  Anyone who has read my previous blog posts, articles or has heard me speak will know that I largely come from the "traditional project management" school of thought or PMBOK.  It's the way I was trained and the way I managed my projects.   Most of the projects I had worked on as a team member were also managed that way.  I am still very much a big proponent of traditional project management.  However, after taking on a new project management position a little over six months ago, I've been open to the possibility that the traditional approach hasn't been working for me as the most effective approach in my current environment.

I wasn't always sold on Agile.  At best, it seemed like something that worked well for software development but that it had limited application outside of that.  At worst, it seemed like just another fad that people would drone on and on about and then fade away at some point.  Something that Agile has never been lacking is a strong crop of passionate evangelists.  They almost seem cult-like at times.  Many Agile practitioners I've met/spoken with often seemed to give out that "holier than thou" vibe.  From my experience, there seemed to be two types of Agile practitioners; those who actually followed a true Agile process and those who called themselves Agile as an excuse to be lazy and not have to adhere to any set schedule or quality standards.  I've had my experiences with both.  Yet, here I am crossing the chasm to be one of them (the former, not the latter).

The project environment I'm in consists of small teams (2-3 people) working on short term projects (average 6-12 week duration) that are largely customer facing software implementations.  Quality and timing go hand-in-hand as my 1A and 1B constraints and I typically have between 10-15 projects active at any given time.  My focus is on delivering the highest quality possible in the shortest amount of time possible with a set number of team members and relatively fixed project scopes.  When I began to have challenges with capacity, efficiency, and timing, I began to take a look at my overall approach.  Perhaps there might be a better way to approach this.  Perhaps there is even a way to take on even more work without working harder.  Could I somehow reduce my stress and at the same time increase my predictability and delivery of projects?  I decided to take another good look at Agile.

I started in the most obvious place, Scrum.  I really liked Scrum and everything that it entailed.  I liked the ceremonies of the daily stand ups, scrum meetings, sprint planning and retrospectives.  I loved the idea of the backlog and burn down charts.  I loved the iterative nature of breaking work into time periods that are filled with all of the things that you can accomplish in that period.  I loved the collaborative approach with self-organizing teams.  I especially liked the flexibility of creating a framework in which to operate that allows for adjustments and improvements to process and enables the team to always be focused on end goal.

However, I couldn't quite connect all of the dots with Scrum.  It was, after all, developed for software development and I couldn't quite get my head around the extrapolation of its application in my specific environment.  We weren't developing software.   We didn't create and deliver statements of work.  We worked on a multitude of simultaneous projects that were customer facing, had similar and repeatable scopes, relied on a predictable delivery date, and were exposed to the changing priorities and commitments of customers.  I couldn't quite get all of the pieces of Scrum to fit in a way that would address my issues of stress reduction and delivery increase.

I would not be deterred.  My search then led me to a webinar presented by Journyx, Ensemble Management Consulting, and Solera Associates in which I was introduced to a form of Agile called Commitment Based Project Management (CBPM).  It was developed at Intel in the 1990's and was not designed for software development.  It uses simple tools and simple rules and enables you to put together a schedule that everyone believes in so that they can give real data about the project.  The team commits to specific deliverables for a time frame (horizon) so that it is clear who delivers what to whom and by when and to what quality standard.  Anyone can speak up about early warnings for dates that might be missed and no one is punished for that.  CBPM incorporates the Agile values of individuals and iterations, customer collaboration, and easily responding to change.  It all made sense to me.  I thought I was ready to take the plunge and present this to the team.

What I brought to the team was a hybrid approach that combined CBPM with elements of Scrum.  We plan in weekly sprints.  We have daily stand-ups and weekly retrospectives.  Our backlog contains the deliverables we have across all projects within that horizon period.  We then map out the deliverables that we will commit to for that sprint.  Instead of stories, we have deliverables.  We don't assign point values to work and we don't track via a burn-down.  A deliverable is either done or not.  Though the team seemed cautious and not completely convinced, they were willing to give it a try.

So off we go into the unknown.  I say unknown because none of us knows for certain how/if it will work and produce the results that we're after.  We do know that it will be "our" process.  We’ll continue to test assumptions, adapt the process to what works, and practice the continuous improvement of Kaizen.  Our goal (or hope) is that we'll increase efficiency better tracking of our work and more insight into our capacity.  We expect we'll even out our workload by only taking on what we can accomplish and proactively adjust the schedule and manage customer expectations accordingly.   We expect we'll be more scalable with the ability to take on more work with equal effort, more predictable as we'll know what we're able to do and when, and more measurable as we'll track our effectiveness and capacity.  We're going into our first mapping session.  We'll see how it goes.

GPS for Projects

by Bryan Peterson on 10/24/10

I'm sure everyone has used some sort of mapping application like Google maps at some point to get directions. I love Google maps. I can enter a starting address and an end address and it can chart a route for me. I could even use the street view and find landmarks to help me find my way. I just plug in my addresses, get the approximate time it's going to take me, get in my car and go. It's great. I know exactly where I'm going, all of the streets, exits, and turns I need to make to get me there, and how long it's going to take.

And so off I go.... And then I miss an exit. A road is closed. Traffic is really backed up. Now what?I've got my Google Maps route printed out, but that was essentially rendered useless when someone decided to send a text message doing 65 down the highway bringing all traffic flow to a stand still. I will most assuredly miss my appointment if I continue on the route I charted through Google Maps. Calculating the percent of my trip I've completed so far is helpful, but it won't get me around traffic.

Now, if I was using a GPS navigation system, it'd be a whole different story. Not only do I have the power of a charted route using mapping software like I did with Google Maps, but now, my plan is living. If I miss my exit, take a wrong turn, or run into traffic, it will recalculate my route and let me know what time I'm going to get there so I can still make my appointment. My plan now becomes an evolving one that helps factor in the variables that I was not able to account for by just using Google Maps. Because my arrival time is also being calculated, I can call ahead and give a relatively precise estimate of when I'm going to arrive as soon as I know.

When we talk about taking your project plans to the next level, we're talking about taking it from a map to living navigation. All of the great things that a project planning/scheduling tool does like Gantt charts, network diagrams, critical path, etc. become significantly less useful once the project gets going if you're not able to compare what is actually happening and use that to modify the plan to achieve the end goal of getting your project completed on time, or within budget, or within scope, wherever it is you need to go.

Here are three simple ways to take your project plan from being a map to giving you turn by turn directions to project completion?

1. Incorporate actuals into your project plan. Integrating your project plans with actual work, actual costs, and completion estimates will help you monitor and control your project progress. You need to have an easy and user friendly way for your project team members to see what their assignments are, track their actual time to those assignments, and communicate how much longer it's going to take to complete. Your team members should also be able to record all of their time in one place, production & support, general & administrative, non-project time, time off, etc.All of this affects their ability to deliver project work.

Many people feel that it is enough to track project progress on a percentage complete basis. But this is just not effective as it doesn't tell an accurate or complete story. Remember, I can see that I'm 65% done with my trip to my appointment, but that doesn't help me avoid traffic. If I call my appointment and say “well, I've got another 35% of my trip to go”, well what does that mean?What I need to be able to say is “I've got another 15 miles to go and it should take about 22 minutes to get there”. Tracking actual time, cost and completion estimates helps me do that with my projects. You can't control what you don't' measure.

2. Put an effective resource management process in place. You need to have complete visibility and insight into resource availability. Which means you need to be able to see not just what projects a person is working on, but also factor in production, support, non-project work, overhead, vacation and leave. When you are scheduling a task, you need to be able to quickly find the person or people you are looking for, understand if they are available, and easily assign them to that work. This not only allows you to assign people to tasks, manage their allocation, and minimizes time on the bench, but it also allows you to have insight into your capacity. That big project you've got coming up next quarter, do you have the available resources to take that work on? What happens if this customer puts the project on hold, what will people do next? By effectively managing your resources and gaining that valuable insight into resource availability, you'll be able to know.

3. Incorporate real-time reporting. Tracking and measuring all of this data is useless if you can’t see it and do something with it. No one wants to take time from their busy schedules to sit around and discuss what they are working on, how much is left, and how it is going. They just don’t. Yet this is necessary data for the project manager. If you have a way to have accurate data right at your fingertips, you can avoid the “endless status meetings” and everyone can focus more on actually doing work and less on meetings.

It is impossible to make effective decisions when you don't know what people are working on or how the projects are doing. As Project Managers, we just want to know what's broken or about to be broken. We are problem solvers, and we cannot succeed with bad, late or incomplete information. “What's wrong and what do I need to address?” is usually the first question on our minds at the start of every day.

You need to be able to extract and analyze data. The easiest way to do this is to have some sort of centralized reporting mechanism where each person can organize their data the way they want and produce the analytics they need in order to make effective, informed decisions. You also need to be able to have a “one pane of glass” view into all your projects and resources. By having some sort of dashboard or some other visual status indicators you can easily and quickly see what you need to be concerned about.

Integrating your project schedules with a process and solution that gives you actual time and cost tracking, completion estimates, resource management and detailed reporting provides you with this information. Don’t just look at a picture of how you want the project to be. Get a view of how it really is, so you can step in and fix things when necessary. Don't just use a map, use navigation.

Blending Professional Services and Traditional Project Management for Enhancing Customer Experience

by Bryan Peterson on 10/24/10

There is a rising trend where product centric and development organizations and professional services are becoming more and more intertwined in order to manage and deliver a successful customer experience. More and more product-centric organizations are incorporating a professional services offering. At the same time, more and more services based organizations are incorporating products and their development into their offering.

In their excellent book, The Experience Economy, authors Pine and Gilmore make the point the goods and services are no longer enough. In order to be successful and achieve growth, companies in today's economy must offer their customers a trans-formative experience that most often requires the product and services to be one and to be tailored to the specific customer. This is more than “blurring the line”, but actually removing the line between products and services. 

It is no longer adequate to only deliver our products and services to customers on time, within budget and as scoped. Companies today must also provide that positive customer experience, which includes successful project delivery and much more. Customers today are not just looking for solutions; they are looking for results. Real, tangible, measurable, and valuable results. Results are going to incorporate processes and people in addition to software and technology. Addressing, managing, and integrating all three of these elements is the only way to effect lasting and trans-formative change.

To accomplish this, product development and professional services are becoming more aligned and assimilated. More and more product-centric organizations are seeing that a professional services offering helps greatly to expanding the product base and revenue stream. By initiating, developing and managing services-centric organizations within product-based companies, companies are able to provide a better experience to their customers and thereby increase revenue. As many of these experiences need to be tailored to the specific customer, more service organizations are finding the need to not only add products to their offering, but also the development and customization of those products as well. As such, more and more professional services organizations are incorporating traditional project management methodologies as the services and development components are often incorporated into a project. All the while, services organizations are looking to reduce non-billable hours, streamline processes, and increase overall efficiency.

This is also inline with a recently increasing trend of mainstreaming of project management. We're seeing project management being offered in most business schools, Masters degrees in project management are becoming more common, and more more parts of the organization are adopting some sort of project management methodology that traditionally had not done so. We're seeing it moving both ways. Formal project management methodology is beginning to move down from formal projects and the PMO into more parts of the organization. At the same time, other parts of the organization that had traditionally not been project oriented are moving up to incorporating various forms of project management; finding that project management is becoming more adoptable and approachable.

This is also giving rise to the “accidental project manager”. People who are not formally trained in project management but who posses applicable domain expertise and find themselves filling the role of a project manager out of necessity.

This all leads to organizations having a very broad spectrum of active projects and initiatives with both development and services components. Often, these vary is size, scope, priority and impact all throughout the organization. At the same time, that more and varied projects are going on, organizations are needing to be more focused, look at things more holistically, and be more proactive of managing what the organization is working on how well they are doing it.

Differing Views of the World

Professional Services focused organizations and Product Development centric organizations typically see the world differently. For example, development organizations focus on successful project delivery and being able to move on to the next project; services organizations focus on the expected revenue and being able to deliver in order to recognize that revenue. Development will look at resource capacity in order to answer the question “do have the available people to complete this project and should we take this project on” ,whereas services will say “go ahead and book it, I'll find the resources and how can I maximize my revenue on this engagement”? 

These days we are all increasingly being asked to do a greater amount of work with fewer people and in a shorter amount of time. Often, our company initiatives and focus can change faster than projects can be completed. Therefore, companies not only have to make greater efforts to complete projects on time, within budget, and to scope as planned, but also to constantly reevaluate the focus and ensure they are working on the projects that are most productive, most profitable and most inline with the company’s overall strategy and mission. This work requires team members with constantly evolving skills who are often geographically dispersed. These challenges exist for information systems departments, research and development departments, and professional services providers, as well as software providers, system integrators and more.

Product-centric organizations, those the make or develop tangible products, usually have good processes established for deciding which projects to fund, planning and resources those projects, and then executing, monitoring and controlling those projects. Service-centric organizations have traditionally worked a little differently. Service organizations provide highly skilled subject matter expertise to define, develop and solve difficult business issues for their customers. While professional services teams are excellent in helping their customers transform and produce desired results, they often don't (or sometimes refuse to) see the problems with or gaps in their own internal processes. It can often take a seriously painful or problematic event in order for a services organization to re-evaluate their project execution process. There is a climate today of increased competition and declining business volume. Unfortunately, too often services firms get wise to this a little too late.

Tying It All Together
Here are some ways to tie together these two sides of the same coin, accommodate each of their different views of the world, and increase successful project execution.

Centralize Resource Management – One key way is to implement real-time visibility of global resource utilization and forecasting. Now resource management and allocation mean slightly different things for development and services. A product development view will look at future resource availability, resource the entire project based on skill and availability, ensure that all resources are evenly allocated, and focus on completing the project on time, within budget and to scope. Services however, will take a slightly different view. For services, it's all about the revenue. They will get consultants working on the projects, often not knowing exactly who that's going to be until right before the work begins, make sure everyone is as “billable” as possible, and work on delivering the project as profitable as possible to the customer's satisfaction. Services groups also have to deal with delays often caused by the client, so being able reallocate work to keep their team billable and all of the work moving forward is vital.

It's possible to have that centralized visibility while still accommodating the needs of each group. The right resource management solution enables managers to calculate the cost of underutilized (“on the bench”) staff. Understanding what this non-productive time is costing the company is very important, and real-time access to resource allocation data allows managers to assign work to available staff, resulting in a far greater return on labor cost. By knowing the associated cost to this non-productive time, you can calculate the avoidance of this idle cost and factor in the increase in productivity. Although the time on the bench will never reach “0”, it is clear to see that by having visibility into your team’s availability and being able to assign work to people who are available, more work can be accomplished faster and you have a far greater return on your labor cost.

With billable consultants, it is easy to dollarize this effect on the organization. By having a central pool of resources and visibility into overall availability, the ability to allocate the right people to the right job, and minimize the time on the bench. If by doing that, let's say you could conservatively add 3 additional billable hours per month for each consultant. And for argument's sake we said your average hourly billable rate was $85. Then for 50 consultants, that would result roughly in an additional $150,000 per year in additional billable revenue. That would be just by adding an additional 3 billable hours per month per person. It would not be out of the ordinary to expect more hours of productivity just by having that “one pane of glass” view into resources.

Of course, this goes beyond just the direct increase in billable revenue. Increases in productivity is another area where you see a substantial return on investment with resource management.

You need to have complete visibility and insight into resource availability. Which means you need to be able to see not just what projects a person is working on, but also factor in organizational initiatives, non-project work, overhead, vacation and leave. When you are scheduling a task, you need to be able to quickly find the person or people you are looking for, understand if they are available, and easily assign them to that work. 

This not only allows you to assign people to tasks, manage their allocation, and minimize time on the bench.. But it also allows you to have insight into your capacity. That big project you've got coming up next quarter, do you have the available resources to take that work on? By effectively managing your resources and gaining that valuable insight into resource availability, you'll be able to know.

Transparency, Visibility and Collaboration

Transparency, visibility and collaboration on projects helps to keep everyone informed about what is going on so project managers can address issues before they derail the project completely. Many experts recommend implementing a simple, easy-to-use system to interface between time tracking, resource management and project scheduling. This will allow your organization to retain processes that are currently in use while still benefiting from increased visibility to crucial data. Conversely, complicated PPM solutions can take a significant amount of time and effort to implement, which can be too much if you are working on projects today.

Software alone will not solve all of your problems, but the right system can provide one "pane of glass view" for all processes throughout the organization. Here are a few important requirements:

  • Complete visibility of resource allocation (including project work, non-project work and vacation time)
  • Real-time status information across all projects with warning indicators and alerts when necessary
  • Integration between work requests, schedules, resource management, project road map and prioritization
  • You need to be able to extract and analyze data. The easiest way to do this is to have some sort of reporting mechanism where each person can organize their data the way they want and produce the analytics they need in order to make effective, informed decisions. You need to be able to see project status, what people are working on, project costs, etc.
  • You also need to have a “one pane of glass” view into all your projects and resources. By having some sort of dashboard or some other visual status indicators you can easily and quickly see what you need to be concerned about.

Use what you've got
Some people believe that in order to improve an organization, they have to "rip and replace" all processes and tools that are currently in use and start fresh. This is not necessarily the case and can sometimes be a big mistake. You probably have processes in place that are working well, and you should leverage these to get you to the next level. Remember, you’re trying to improve upon your current situation and blend these two areas together. But you must acknowledge what has successfully brought both development and services to where they are now and find that synergistic “win-win” relationship. You don’t necessarily have to (or want to) blow everything up and start over. There are probably some things you can leverage to get you to that next level you’re seeking. 

For example, you might find that people throughout your organization feel comfortable using Microsoft Project and others Microsoft Excel. Forcing everyone to stop using these tools and start using a different system could have very adverse effects. An alternative would be to look at how you can enhance and extend the tools, allowing people to keep the processes they are comfortable with while maximizing benefits and value.

Communication also helps if you have employees who are resistant to change. They might be suspicious of your efforts to improve processes when they feel that the status quo is already "good enough." (As Jim Collins wrote in his best-selling book, Good to Great "Good is the enemy of great.")

When bringing together product development and professional services, you've got instill trust in the entire team because their buy-in is crucial to achieving organizational goals.

Here are some things to keep in mind when establishing processes and systems for blending the dynamic methodologies of Professional Services and Traditional Project Management of product development for Enhancing Customer Experience:

  • Accessible. Everyone needs to be able to access, share, and retrieve information, view status and metrics on projects, as well as view and monitor progress and costs.
  • Flexible. Every organization is different. Bringing together separate parts of the organization such as development and services creates an entirely new entity. Always keep this in mind. Consider taking a “meet us where we are” approach when establishing and adopting processes and systems.
  • Interoperable. This is at the heart of what we're talking about here. Managing and entering the same data in different places is wasteful and risky. Integrate your existing and newly established processes, with all of your systems (PMIS, Resource Management, Reporting, Financial, etc.) together with all of your people so you experience lasting and trans-formative results.
  • Scalable. Organizations today have to be lean, agile, and dynamic. The way you do things and what is successful today, may not be tomorrow. You've got to be able to adopt and your processes and systems should facilitate this, not hinder.

Unfortunately, there is no silver bullet for change. A strategy that worked for one company may not be a good fit for another, which is why it is important that you use research and communication to uncover your organization's true needs and the best way to go about this. Only you will know what will and will not be adopted by the organization, how much time and money they are willing to invest, and subsequently, what the best strategy is. Also, do not rely solely on software to fix the problem. It is imperative to integrate your processes and people, and to manage them well. Your software solution will need to empower team members and facilitate their work.

Contrary to popular belief, you can take small steps toward blending dynamic professional services with traditional development and increased organizational maturity. A complete overhaul of your current processes is not always necessary and can sometimes be quite damaging to the organization. Rather, you should do your best to evaluate what works and what doesn't, and implement a system that will give all project stakeholders transparency, visibility and communication. These small changes will not be too shocking to the employees and culture, yet will provide a way to learn from failures as opposed to repeating them.

Experiences, learnings, musings, and opinions on engaging customers directly, personally, and authentically.