What does it take to succeed?

Team skills and culture play a critical role in the success of projects. I have a group of dedicated developers that leave their egos at the door, and work together as a cohesive unit. We are looking for ways to continually improve our overall skills and improve our processes so we can be more effective in managing our projects. We ask for continuous feedback from our customers and adjust our project trajectory as appropriate. We focus on the little things, and try to monitor the pulse on our project to expose potential surprises early, so we can work with our customers to compensate for these changes. Project success is about focusing on how we add value to our customers, and trying to improve this every day, through an iterative approach.

Regardless of the development technique to which we subscribe, if we don't add value and serve our customers, our techniques, and results, are basically irrelevant. We need sufficient process to predict project outcomes, without constraining our potential for success. We need to use common sense and moderation to identify the correct balance for our individual teams.

Here’s some of my basic observations on what it takes to succeed…

1. A dedicated team, and an honest feedback loop – the team is organic, and should feel safe to provide feedback on shortcomings, potential for improvement, potential new techniques, and strengths that can be leveraged.
2. An ego-less culture – staff must be comfortable to brainstorm and provide feedback, regardless of level.  They truly value each other’s opinion, and look for ways to continuously improve processes.
3. A focus on quality, openness, and customer service.  It means sometimes accepting responsibility, even when you may not agree that you are at fault… as a way to move forward.
4. Focusing on the customers’ project, and talking on their terms… in their language.  They need a solution which they can embrace and understand, and not a bunch of technical details which are important to deliver the solution... yet are NOT the solution.
5. Really understanding what the customers’ needs, and asking probing questions to help define and agree up front to the project scope and document the assumptions / specifications so scope creep can be identified.
6. Prototype to get buy-in from the customers… and work with them to adjust the deliverables, resources, or timeline as appropriate.  If the scope changes, negotiate one of the above variables to keep the project on schedule… and provide immediate feedback on impact to your customer.
7. Put together a detailed project plan… with a clear critical path… e.g. 1000 hours out of a budget of 2000 may be 10% complete or 50%... if you can’t tell, then break the project plan down further… and also rely on feedback for % effort complete, don’t go by hours alone.
8. Frequent meetings with your customers to show current progress and get feedback.  You’ll find that they often missed important details as you demo project progress at weekly, biweekly, or monthly meetings.
9. At every meeting, update your timeline… if there are risks, identify them early, and discuss them with your customer.  I would want to know early if my house won’t be finished for a few more weeks… not after I have the moving van packed and I’m on my way across the state.  Give your customers the same courtesy.
10. Evaluate new tools and techniques.  Pick some unobtrusive way to test these, and adopt new processes and techniques after you've proved their value.
11. Find ways to innovate transparently.  One of the recent things we've done is to deploy code without an interface, and off… so we can evaluate performance with the function enabled, and not visible.  It's easier to remove this via a setting, and the customer isn't disappointed because a feature needs refactored to perform at scale.
12. Recruit and develop your staff for success.  Get staff that share the same dedication to customer service, and make them comfortable in your environment.  Look for team players, and provide them continuous feedback.  Reviews should be a reinforcement of feedback you provide on a daily or weekly basis… and nobody should be surprised… or there is a management failure.
13. Quality should be part of the process, as should involving customers in the testing and acceptance lifecycle.   It shouldn't be an afterthought.  If we consistently require heroic efforts, then we need to review to see where we have failed in the planning and communications process.
14. Ownership doesn't end when code is submitted, it’s a lifecycle approach, and shared across the team.  It’s part of that continuous feedback loop.
15. Recognize your team for their results, and make sure they get the credit that they deserve.

In the end, it’s all about finding the right balance of tools, processes, and techniques to improve the services you provide your customers.  Ask, and get feedback... and be sure that you are capable of humility and openly accepting all comments.... even those for which you may passionately disagree.  Perspective and lens are individual, accountability and goals are not... so keep your eye on the prize and evaluate against measurable results, not effort.

Research Projects vs. Continuous Improvement for Production Services

There should be a clear distinction between a research project and a production service.  I’d like to do a brief contrast and comparison of where these overlap, and where the concepts diverge.  Let’s say a developer want’s to introduce a new process change into the development life cycle, or into the hosting life cycle.  How do you define if what’s being change is part of continuous improvement, or is a research project?  There are several litmus tests…

1. Has the technology been proven in a pilot process, and is there a direct proven benefit to product quality, stability, and customer service?
2. Is the outcome learning or proving the value of a technology?
3. Has the technology been proven, and is the application of the process or technology easily repeatable for other applications?
4. Is there a measurable benefit, and is the risk from the change mitigated with an expected benefit?

To contrast and compare…

Attribute	Research Projects	Continuous Improvement Project
Expected Value	Knowledge, any other value is a bonus	Either explicit, or intrinsic improvement
Cost Recovery Model	Sunk / No Option for Recovery	There is a payback or cost recovery period
Proven Technology	Proves Hypothesis	Yes, this is either an application of a technique to a new system, or an evolution of an existing process.
Known Outcome	No, the potential for improvement may be radical, however the risk is unknown.	Yes, with a very high likelihood of success
Level of Risk	High, first tested on low impact situations	Low, the technology has been proven.
Production Ready	No	Yes

A continuous improvement project is one that improves on existing processes in a risk-mitigated fashion.  It is evolutionary in nature.  Research projects are attempts at revolutionary changes to processes, and are equivalent to a larger scale lab project to learn more about a process, and to evaluate the potential for improvement.  Once research projects have been proven, then the new process is mapped to existing processes, and a gap analysis is completed.  As part of the gap analysis, production processes are compared as evolution using moderate steps through continuous improvements to reduce risk.  Research projects are similar to a petri dish experiment… and can be anything from a proof of concept, to a radical change in processes or technology.

Because production services are expected to be stable, changes are introduced using a method that reduces risk.  The change is normally evolutionary, with prior proven steps, and a proven change management process.  Once the research project has proven successful, then it needs to be mapped, and evaluated based on its potential as a production service.  This means looking through the lenses of stability, customer service, process improvement, efficiency, and value.

I’m not adverse to radical changes.  However these should be first proven on services which have a higher tolerance to disruption, and then migrated up the service chain.  The exception of course, is when you are not meeting service commitments for a critical service, and can take a measured risk that the radical change will improve the service.  Unstable systems have a different criteria for change than proven stable systems.  There are a number of reasons why a system can quickly become unstable, including changes in infrastructure, rapid adoption, and inadequate sizing – all of which should be mitigated, where possible, with adequate testing.  Like the commercial from a few years back… if you click the go-live button, and you are an overwhelming success beyond your wildest dreams, you could have a scalability and stability issue you need to address with radical changes.

That’s it for now… Happy Computing!

College Prepares you for LIFELONG LEARNING, NOT LIFELONG EARNING!

Think about your college education... what do you remember most?  Was it a formula used to calculate current or quick cash flow ratios?  How about calculating the net present value of an annuity, or what the "rewind command" means in Fortran 77, or what a z-test is used for?  Or was it the research paper that frustrated you because it was loosely defined, and you had to actually think for yourself?

I want to be brutally honest... college is about BUILDING FOUNDATIONS. Learning is not a point it time accomplishment, it needs to continually evolve.  If you believe that by spending two, four, six, or eight years in an institution of higher education, you've written your ticket for lifelong earning... you're sadly mistaken... you OWN your career... not your employer.

You are paid based on the value you provide to an organization, sometimes measured by improved efficiency, increased sales, improved profits, by building more widgets, or possibly.... you have the same last name as the owner, and it's easier to pay you than just give you money.  When you fail to contribute in a positive manner, you are no longer of value to the organization.  You own this responsibility, not the organization.

I'm amazed as we interview people how few really take ownership for their career.  They believe college initially prepares them, and that each of their future employers should train them in new processes, techniques, and ensure that they remain marketable and competitive.  When their skills aren't sharp, it's someone else's fault.  What would happen if nobody innovated, learned new methods, new manufacturing techniques, new design processes, etc.?  The company would disappear, and there would be many staff that could not easily find a new job with their skills... and that complain that the "old company" failed them because it was unable to keep up and that their careers were short changed.

There are situations where this occur... and that's sad, these are short sighted companies that normally don't last long.  If there were a few people willing to take risks, and invest some of their personal time... the story could change dramatically. The organization could move from a company that lacks focus and vision, to one that looks for continuous improvement and takes calculated risks in order to continually improve and grow.

So, next time someone asks you what you've learned recently... think hard... and be honest with yourself. Seek opportunities to learn, engage your employer... find funding... find small projects to test your ideas and succeed... and really listen. 

I've found that the best ideas often come from line staff that nobody will ask.  These are the blue collar workers on the assembly line... they carrying the burden and blame when quality suffers, or productivity drops... yet they are not often asked directly what can be done to improve their processes or the products they create. Out of necessity, these people usually have broad "hands-on" skills that they can leverage, or knowledge from another area they can apply.  These staff can be extremely innovative people that have learned to build houses, repair cars, and continually learn in order to be able to afford every day life.  They don't have the option of calling someone and saying when can you get this done?

So, take control of your education, and ownership of your job... stretch... and reach outside your comfort zone... innovate... share... learn... and grow.  College didn't teach you to be lazy, life is a moving target, and sometimes it's tough.  Put on a helmet, focus, and become engaged!