Some people say process leads technology but I think it's usually technology that leads most peoples' decisions because it's so shiny.
There's an order to getting things done with technology that should be followed to be successful and not spend too much or buy the wrong thing. What we ultimately want in life and business is processes or flows that serve us in efficient, effective, fun, valuable, and entertaining ways. To get these flows (ideal experiences), though, we have to follow a very structured process and invest in technology and experts. The process starts with technology identification and selection, then leads to people and experts, and then finishes with you (hopefully) getting the processes that you want.
Technology. The technology selection part is fun. My mom's looking to get an iPad soon and she's excited about that. Looking at technologies is fun and we can learn a lot by studying them but we have to first know our goals and criteria. We can and should build our ideal process requirements in this phase.
Then people. The people part of the process can also be fun and enlightening. This phase is about bringing in experts or geniuses to support you in learning and achieving your goals and objective processes. You'll find that many of the geniuses out there have a vested interest in *their* technologies or solutions and are not necessarily customer advocates. True business analysts, managers, and customer advocates inquire with the customer then select only those technologies and suppliers that can meet their long-term, strategic needs.
Then process. The process part is also fun and where the rubber starts to meet the road. In this phase, it is about putting the technologies and people you bought into a practice and flow and making it work for you for your objectives whatever they might have been.
In review, working with technology is fun but we have to make sure we surround ourselves with advocates for us who help us get the technologies we need to achieve our process objectives.
Survive and thrive in our competitive, connected business and technology world.
Showing posts with label process. Show all posts
Showing posts with label process. Show all posts
Friday, April 27, 2012
Friday, April 20, 2012
A learning model for professional services organizations
![]() |
It sure would be nice to have a manual. It shouldn't be that hard for our groups to make one. |
I just recently started a job that had next to no training provided to me. Without it, I had to go find people and resources on my own to give myself even a small clue of what I needed to do. And even then I didn't have enough information and it made it way more complicated than it needed to be.
While there, though, some colleagues and I built a model that provided us the training we knew we all needed. We saw training being delivered in three levels: A) our roles B) our accounts and finally C) our projects.
Role level. We agreed that by first focusing on our roles, we would be able to help each other become excellent at what we do, individually.
Account level. We next decided to focus on our customers and accounts. We felt that the politics and preferences of our customers mattered a great deal and that there was a big need for teammates to be trained on accounts.
Project level. The final thing we knew we'd need to focus on was our projects. We agreed that our projects should be the simple part of this. We all know what we have to deliver and fit in, so the training here really should be minimal.
By training and accumulating knowledge at these three levels a professional services organization can learn, continuously improve, and deliver the maximum values to its customers.
Unscrew screwed situations
![]() |
Don't just be any tool, be a screwdriver. Be the one that can drive change in one direction or another and try to make sure it's positive change that people want. |
Doing this is an art and science, and a risky, difficult one at that. To do it successfully, you have to be really careful of the people and goals and get everyone thinking and looking in the same direction. Have you have to identify key bottlenecks and remove them one by one until you can see out. Communicating effectively up during this time is also difficult, yet critically important.
Dive into organizations and find out where they are most screwed up. Be the change that is required to correct the problem and point it into the direction that you believe.
Labels:
change management,
leadership,
organizational change,
politics,
process,
tools
Saturday, March 31, 2012
Front-office and back-office folks: and getting to trust
![]() |
Creating the right perception is tricky and risky. First you have to know and trust yourself. |
Life and selling are processes; they're complicated.
In life we have to choose between those people we rely on and trust to deliver for us (the back-office people) and those people we choose to sell for us (our sales or front-office people).
I've stated in previous posts today that I need to grow my team of sales people and advocates. I need personal advocates who can help me sell my value and what I offer. I also need people to help me deliver what I can deliver, but I think I need fewer of these people.
In all, I need to trust myself before I need to trust others. But if I can get to a place where I trust myself then I can surely get to a place where I can trust others and hopefully one where others will also trust and advocate me.
Why processes?
![]() |
Sometimes the thing and the thing behind the thing are equally compelling. |
We can parse this word a little further and think about what a 'thought process' might be. It would be something going on in someone's head which makes slightly more sense. I think therefore I am. I think therefore I have thought processes or things in my head. That makes some degree of sense. But again, so what?
I have argued in the past that a process is 'anything that takes time'. I'm not sure what this means but I still like the idea.
They say that systems are collections of processes which makes things even more confusing to me.
Purpose and intention (the reasons behind processes) are far more interesting to me than processes. But studying processes helps us understand why things might be.
Everything is better on a team
![]() |
We are not alone until we think of ourselves as such. |
When it comes to sales and selling the same holds true. I like to sell by myself but I do not love it. What I love is the idea that I can sell as part of a team and system, rather than as an individual.
We need to find ways to take ourselves as individuals out of the picture and figure out how we can grow teams around ourselves who love and support us in our efforts and interests.
We need to get excellent at having others help us. The more we can define a process and system for growing, selling, and success, the better off we all will be.
Make sure it's sustainable but don't be boring
Doing things that are fun and cool and creative and off the wall are interesting but they're not everything and sometimes they're not sustainable at all. We shouldn't expect that all of our practices are sustainable but we need to makes sure that the bulk of the core ones are. In this way we have to have great values and focus.
We have to make sure that the core and essential set of our practices are sustainable but we don't want to get caught up in only doing the mundane. Finding this balance is hard.
Labels:
creativity,
drudgery,
mundane,
process,
systems
Build systems for yourself and others and win
![]() |
Do things that work for yourself and for others. Two birds, one stone. Lead. |
When we can build things that work for us and others we're winning, we're selling, we're growing and building teams. Do this every day.
Sunday, November 29, 2009
An Easy-To-Follow, Scalable, Agile Process for Anything
In this article, I outline a quick and easy-to-follow process for getting lots of things done (the agile way). I think you'll find it useful and informative. It doesn't matter if you're scheduling improvements to your home, hometown, or business, you can follow this process on any and get results.
- Note the request(s) (high level) in the backlog…you don’t have to understand what it is fully…just the gist of what’s being requested. Make sure you include who its from and anything else. Make sure it's fluid, too, and always be willing to go all of the way to the end of the process if the rules allow. Don't let yourself or the process be the bottleneck!
- Backlog and prioritize this work. Figure out where the request should sit in the queue. Use a method like FIFO or LIFO as a reference. You could also create a "value index" to score the cost/benefit of the request. Sometimes you may choose to do ANYTHING you can just to demonstrate value and show the customer that you are doing SOMETHING toward their objectives.
- Define the request in concrete terms including the problem, required output and success criteria. This may also include the specific implementation method and input required to get the job done. Be clear what the customer needs and make sure there's a clear agreement and understanding of output at this time.
- Optionally train the person(s) performing the work—even if it’s yourself—how to do the tasks necessary. Remember the goals and make sure there is no "loss" in the communication process.
- Assign the work and start executing.
- When the work is reported to be completed to spec by the person, verify. Repeat this step until you accept the quality. Note: you could see all changes you make here as backlog items as well, so beware of "churn" and be fair to the people and process (team!).
- You may queue or hold the result at this time as to efficiently deliver a collection of things to your customers or you may deliver it as well. Queuing your results will promote longer, larger cycle times but could be more efficient for your business. Delivering now will shorten the cycle and create for much higher customer interaction, which can be good, especially for very small teams (even teams of one).
- Deliver the result to the end customer. This is a similar verification (validation?) process but is facilitated by you, the process owner; that way expectations and feedback can be set and the overall process and deliver method improved.
Labels:
agile,
business process engineering,
process,
scrum,
work
Thursday, March 06, 2008
Making Companies is like Making Movies

There's a lot to be learned from Hollywood for the production of software. Making software isn't (or shouldn't be) all that different from making films. Since the early 1900's, Hollywood has been pumping out film after film. Technologies have of course changed over the years but the end product of a motion picture remains. Software is similar. Hollywood's "simple" process of pre-production, production, and post-production is a powerful tool. And its simple roles of Scriptwriter, Producer, Director, Actors, and Post-Product workers are powerful if applied to software projects.
PRE-PRODUCTION ROLES:
Scriptwriters
In film, these are the story tellers.
In software, these are also the storytellers. Their titles, however, are Business Analyst, Product Manager, Requirements Engineer, or Process Engineer.
Producers
In film, these are the guys that get the money and form the team.
In software, these are the Project and Program Managers (or above) who get the money (from investors or internal sponsors) and form the team.
PRODUCTION ROLES:
Director
In film, the director is responsible for the creative work and directing the actors.
In software, the IT Project or Program Manager does the same thing. The actors in software are the designers and developers who are creating the end product for the customer.
PHASES:
Pre-Production
In film, this is creating and refining the script, getting the actors, having a plan, and budget.
In software, this is creating and defining the software, getting the developers, having a plan and budget.
Production
In film, this is "shooting" the film and having the actors act according to the (sometimes changing) plan.
In software, this is "coding" the software and having the developers code according to the (sometimes changing) plan.
Post-Production
In film, this is the work involved in creating the final product of sufficient quality.
In software, this is QA work and is generally iterative where things are returned to developers to fix.
Iteration
In film, iteration is common. Many "takes" happen.
In software, iteration is common. Much "rework" happens.
So in total, I hope you can see that a patter and relationship emerges between film and software. They're the same. They're both productive processes generating a product for an audience. Applying more of our knowledge of the film industry and how it works to software would improve development lifecycles, decrease budgets, and improve user-satisfaction.
PRE-PRODUCTION ROLES:
Scriptwriters
In film, these are the story tellers.
In software, these are also the storytellers. Their titles, however, are Business Analyst, Product Manager, Requirements Engineer, or Process Engineer.
Producers
In film, these are the guys that get the money and form the team.
In software, these are the Project and Program Managers (or above) who get the money (from investors or internal sponsors) and form the team.
PRODUCTION ROLES:
Director
In film, the director is responsible for the creative work and directing the actors.
In software, the IT Project or Program Manager does the same thing. The actors in software are the designers and developers who are creating the end product for the customer.
PHASES:
Pre-Production
In film, this is creating and refining the script, getting the actors, having a plan, and budget.
In software, this is creating and defining the software, getting the developers, having a plan and budget.
Production
In film, this is "shooting" the film and having the actors act according to the (sometimes changing) plan.
In software, this is "coding" the software and having the developers code according to the (sometimes changing) plan.
Post-Production
In film, this is the work involved in creating the final product of sufficient quality.
In software, this is QA work and is generally iterative where things are returned to developers to fix.
Iteration
In film, iteration is common. Many "takes" happen.
In software, iteration is common. Much "rework" happens.
So in total, I hope you can see that a patter and relationship emerges between film and software. They're the same. They're both productive processes generating a product for an audience. Applying more of our knowledge of the film industry and how it works to software would improve development lifecycles, decrease budgets, and improve user-satisfaction.
Subscribe to:
Posts (Atom)