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.