It’s important that you take time, with some regularity, to step back and observe what’s really going on in your organization or business. Look around and see what’s going well and what’s not. What could you change to increase the efficiency or effectiveness of the team of people that you lead? This is part of what I call business development and it’s critical to you being able to step beyond where you are today and move forward to where your vision is taking you tomorrow.

In the Hunt
If you’re always in the moment then you’re focus is always on the the “now” and many times that’s a distraction or a diversion from where you envision yourself to be in the future. I call this being “in the hunt.” I’m a technician at heart; I’m a doer. I am happiest when I’m getting lots of stuff done. To me, it’s kind of like being in the process of hunting, tracking, or chasing something down. It’s exciting to me. My natural tendency is to react to things. You have a problem, I have a solution. There’s a fire, let me put it out. And on and on the list goes. These types of people are great people to have working for you in your organization. We like problem solvers and doers. But, they’re not necessarily the type of people that you want shaping and forging where your business is headed.

The point is, if you’re head is always down, working on whatever the problem of the day is (and believe me, there are problems every day), you never take the time to stand up, look around, and identify what the cause of the problem was in the first place. And though you may be able to make it past all of the problems that come your way in a day, you may never get beyond the problems of the days to come. This will seriously hinder your ability to make progress.

If you’re a leader within your organization (i.e. maybe you own your own business or you’re managing a team of people), your job is not fighting the fires or in the trenches fighting side-by-side with your troops. Your job is figuring out why there’s a fire in the first place and fixing that, or why you’re fighting someone else at all when you should be working together for the greater good.

Business Development

If you are a technician or a doer like me, this next little bit will likely sound like a really good idea and will make perfect sense, but will be excruciatingly painful for you to implement in your day-to-day lives. I’ll make some suggestions in this section of the article that will hopefully give you some tools for implementing the practice of business development slowly into your regular routines.

I’m a software engineer by trade. The work that I’m trained to do is software development. If you’ve ever been involved with a software development team, the process of software development is broken up into phases. Each of these phases together comprise the Software Development Life Cycle (SDLC) . I believe that these same formal practices that are used by software development teams to successfully deliver software can be applied to the problem of business development. The practices that together make up the SDLC are listed below.

• Analysis: Understanding the problem or requirements and determining a solution or plan.
• Design: What the solution will look like and how it will fit into the overall architecture.
• Implementation: Sitting down and doing the work to implement the solution as it has been defined by the analysis and design steps above.
• Testing: Determine whether the newly implemented functionality meets the requirements and doesn’t break any of the existing functionality.
• Documentation: It’s critical that newly created processes or features are documented so that the value that they add can be fully realized.
• Maintenance and Support: Keeping the code and documentation clean and up to date and keeping the customers happy.

One final phase that is sometimes built into more formal and advanced SDLCs and that I would sneak in somewhere between testing and maintenance/support is the practice of gathering metrics.

• Metrics Gathering: Measures how effectively the goals of the organization were attained.

The practice of business development requires that you take yourself out of the hunt long enough that you can really look at or analyze a situation, come up with a practical design that will produce more advantageous results in the future, implement the new process or procedures within your organization, define tests to determine whether the new process is operating acceptably, define and capture metrics that will help you indicate the new procedures efficacy, and then finally document the new procedure for communication and training purposes. The maintenance and support of the new procedure is the process of putting your weight behind it as a leader and ensuring that the people on your team understand why things are changing.

It sounds like a lot of work, I know. But the truth of the matter is that if you’re not doing something each day to increase your business’s or team’s ability to operate more effectively and efficiently then, at best, you’re standing still and making no progress toward your vision of what you want your business or organization to be. If you take the time regularly in your day to really look at what’s going on around you in your business or organization, you’ll see more and more opportunities for improvements that, if acted upon as I’ve suggested, will accelerate your journey down the path to realizing your vision of what you want your business to be. And, if you’re working for someone else and applying these principles for them, the people around you will quickly realize the value that you add to the organization, which will surely ensure your ascension to the upper echelons within the organization.

Posted in Business Development | 27 Comments »

Getting Your Processes Down

Wednesday, January 27th, 2010

Lately, I’ve been in to identifying the processes that make up the majority of my daily activities and getting them all down on paper (electronic paper that is). I currently have a group of developers who work for me, and while we’ve enjoyed some success, I can’t help but think that we would be that much more successful if we could consistently duplicate our successes while re-evaluating or eliminating the processes that have produced less than stellar results.

Why this may be important to You

The purpose for documenting processes is to optimize, automate, and more consistently reproduce the successes that you or your team has each day. In other words, try to identify things that you find yourself doing repeatedly at work, in your business, or personal life and document the steps that you take to accomplish these types of tasks. Once you’ve documented the process for accomplishing a particular task, review the process steps with a peer or friend and try to think of ways that you might optimize or more efficiently accomplish the task.

If you define your process in enough detail, you’ll ideally end up with a task that can be outsourced. That means a task that can be turned over to someone else all together for execution (e.g. co-workers, employees, kids, partner, virtual assistant, etc). The idea is that you work your way through all of your regular processes, optimize them, and then turn them over to others for execution. This should leave you with a lot more time to focus on the most important aspects your work, business, or personal life.

How to start?

Of course, the difficulty with documenting any large and/or complex system (like your life, work, or business), is getting started. When I approached it, it seemed so huge that it was difficult for me to just take the first step. My general philosophy when it comes to things that are overwhelming is to “do something… anything,” just to get the ball rolling. So I decided first thing Monday morning I’d start documenting whatever I happened to be working on and just see how it turned out.

Steps for Process Documentation

First, before we get started, I thought that I’d give you the run-down of the general procedure that I used for documenting my processes. I think that they are general enough that they could apply to most anything that you might run across.

1. List the steps involved in accomplishing the targeted task.
2. Review the process steps with a peer and ask for feedback.
3. Ask a peer, your employee, or partner to execute the process on their own as a trial run.
4. Evaluate the results realized by your process.
5. Revise your process and redo steps 1-5 until you are satisfied with the results the process produces.

Now Back to My Story

There were two processes that I targeted for the trial run. The first was our development team’s Iteration Tasking Process. This is the process that we’ve followed in the past for taking the stories that are defined as part of our development iterations and tasking them out so that work can begin on them. The second process that I tackled was the New Employee On-boarding Process. This is the process that we follow when a new developer is hired.

I wrote the first of the two processes, the Iteration Tasking Process, down prior to the Iteration Tasking meeting that I hold at the beginning of each iteration with my development staff. I first explained my purpose in creating the process, then I took them step-by-step through the process to orient them to it. I also gave them the opportunity to provide feedback to the process and if we all agreed that the suggestions made were good, we incorporated them right then and there. Once the process review was complete, I assigned each of them a story to task, instructing them to follow the process as closely as possible, and turned them loose. We planned to reconvene in a couple of hours to review the results. The results of the first execution of the process steps were mediocre and it was obvious that there would be some growing pains while the development staff got used to the idea of the new process. It also identified some deficiencies with the process where further elaboration would be required to be able to achieve the level of consistency that was desired. All-in-all, I chalked the test run of the Iteration Tasking Process up as a success. We not only defined a process that we could all live with but the process of evaluating and refining the process had already begun to improve it. A good first step.

Phase two of process testing was the New Developer On-boarding Process. This process happens to be complex because my development team works as government contractors (many, many forms and signatures). Luckily for this particular process, I had a good starting point: one of the team leads of one of the other groups had already created an on-boarding document with many of the required steps already included. So, I grabbed the document from her and started down the path of creating the New Developer On-boarding Process. This is one of those process that isn’t necessarily performed very often, but, if you don’t know what you’re doing when you have to perform it, it ends up taking a lot of time. The final test of this process will not be performed until Monday morning of next week, so the jury is still out on that. However, I fully expect that once we run through the process a couple of times, re-evaluate it’s shortcomings, and optimize it for efficiency, we’ll end up with a process that will save us a lot of time and effort when new developers come along.

So, my first attempts at process documentation and development seemed to be a success. It was also quite surprising how satisfying it was to see our processes down on paper, written out clearly, in a form that could be easily duplicated. The next steps for the process documentation experiment will be to continue to work through each of the many processes that make up the majority of what we do each day, putting them down on paper, and then testing and reworking them for optimal performance. My hope is that as we get more and more of our processes documented and optimized, I’ll be able to roll more and more of the day to day activities that require so much of my time off onto others for execution without the worry that the results won’t match my expectations.

You too can recoup much of the time that you spend each day on non-critical repetitive tasks by simply documenting those processes, refining them until the desired result is consistently obtained, and then handing the process off to others for future execution.

Tags: Automation, working the system
Posted in Automation, Work The System | 7 Comments »