Tag Archives: business operations

3 Signs you over-thought it!

by

How often are we faced with a system, process or application that leaves you frustrated and confused? Based on my own experiences this week, and that of many of my friends (thanks social media), it occurs pretty frequently. Feeling inspired by all this disfunction leaves me thinking about how we can quickly assess whether we have made it overly complex.

over-engineered-system

  1. It’s difficult to maintain – A well designed process or system is one that is easy to understand it’s purpose, and intuitive enough (or simply documented enough) for someone to maintain it. Our environments are not stagnant so we can expect our processes or systems to be.
  2. Users complain about it (or just don’t use it) – Processes and systems are designed to solve a business problem. If we make them so complicated and cumbersome users won’t use it, and if there is no other choice, will complain relentlessly about doing so. If the system or process requires more people to enforce it, then it’s time to take another look.
  3. It’s not delivering the quantifiable measure of success you thought – Again, you implemented this to solve a business problem. Hopefully, you defined a measure of success. If you are only seeing marginal improvement, or even a decline in performance against the business problem, this is highly indicative of having over-thought your solution. It’s may be time to start over.

I don’t think overly complicated systems or processes come from a malicious place, however they can be detrimental to the overall success. Be conscious of these warning signs and be aggressive if fixing these. It will make for a better overall user experience improving morale and positively impacting the bottom line.

To read more on this topic, see these blog posts by Gregory C. Smith, Code Simplicity, and David Meehan.

3 reasons to embrace your most vocal customers

by

So, you’re in the middle of a project and your customer spent the last 15 minutes telling you all the ways the are frustrated with how the project is going, and what you need to do to fix it. As a project manager, this can be quite disheartening. Often we put so much of our selves into our work and it’s hard to hear that your falling short. That said, I think we need to view this scenario from another perspective. Here are 3 reasons to embrace this vocal customer:

improvement_construction

  1. Engagement – If your customer is taking the time to vent their frustrations with you they are still engaged. At this point they still want the project to be successful and haven’t given up on you as a vendor. You still have work to do to resolve issues and mend the trust issues, but they are enabling you to do this.
  2. Improvement – Your most vocal customers are the ones that are pushing you to be better. These customers are sharing their intimate business challenges and opportunities and asking for your help in solving them. While it can be frustrating and  the relevancy to the organization may be foggy, this customer has chosen you to help them. Working closely on defining solutions together allows you to do a better job servicing other customers in the same industry.
  3. The alternative is futile – Doing nothing to respond to your customer’s concerns sets you on a very difficult path. This will ultimately drive your customers away. They underlying business requirement doesn’t go away in this situation so if you aren’t helping to solve it, so other vendor will. Additionally, if you aren’t constantly listening to the changing landscape of your customers’ industries, you aren’t able to iterate to solve those challenges.

Next time you are feeling a bit attacked by your customer, take a step back to breath and recover. Once you relax and realize this isn’t a bad thing, then you can identify your plan for exceeding expectations and delivering to the customer.

Make sure you apply what your expertise to your own practice

by
captain_obvious

Source: https://twitter.com/obviouscapn

I strongly believe in documentation. As a project manger, I feel that’s I am in the best position to properly capture the twists and turns along the project path. Given this, it makes the most sense for me to at least do the initial drafts of the documentation. There may be times where technical resources need to provide more details around how something is implemented, but for the most part I know enough to provide the starting point. This applies to both business documentation and ongoing production support documentation. I consider this core to what I do as a professional when I manage any project, at work or on volunteer initiatives. After quitting one job, I stayed on for another 3 months to hire my replacement and ensure the documentation was complete and up to date. Three years later, after some personnel turnover, I was asked to come back as a subject matter expert. I resurrected this documentation, refreshed it and used it as the basis for addressing the questions.

Despite all that, my biggest take away from last week’s DrupalCon was that my business needs process to scale. Yes, I know that it’s obvious. I do this all the time for my client work, ensuring that someone could take over my projects with relative ease. In those scenarios, someone taking over would find an archive of project artifacts previously provided to the customer, a site with the project details including other relevant reference sources. The outstanding work would be documented per the client request (i.e. task lists, service tickets, etc).

I have even started this for processes that are outside of my core competencies. If it was new, I needed to document the process for me and my partner so we could reference it, measure it and update it as required. It’s all the other stuff I haven’t documented. To continue the example of someone taking over my client work, while they have the tools, they won’t have the instruction guide. They won’t know how I go about a project. They won’t know how often I communicate with the client or in what form. There won’t be a guide for what to do the first day they step in.

It’s disturbing that the things that are most obvious to us are often the things we overlook the most. Regardless of how valuable we think we are, we have to plan for the unexpected. This could range from tragedy like sickness or death or joyful opportunities like extended holidays in locales with limited connectivity (yes, those places still exist). We limit ourselves when we only share our talents externally. We need to also apply our expertise to our broader roles and organizations. In my scenario, building these processes for how I do what I do will allow my company to grow. For yours, you are adding value not just to external customers, but also creating significant value for the organizations we engage with.

I hope after reading this you think about your core competencies and whether you are truly practicing what you preach.