Recipe for Success

Why is it that some of the biggest IT consulting companies in the world do some the most mediocre work? Why is it that so many startup consulting companies start out as the greatest places to work with a string of enviable success stories and dramatic growth, then slowly degenerate into mediocrity?

I’ve been thinking about this, and thinking about how Thinknostic should develop and that gets me thinking about fast food franchises.

The genius of franchises, particularly fast food chains is the consistency they achieve at reproducing their product. The product is generally rather mediocre but every meal is as good as the last one in exactly the same way. You can walk into any restaurant in the chain anywhere in the world and order your meal with assurance that you have no chance of being surprised in the slightest.

The secret to achieving this is that they rely on a system. The real secret sauces are their operations manuals, that describe in exhaustive detail the exact procedure that every franchisee must follow to create and deliver product. If a burger is grilled at 350 degrees for 50 seconds per side in New York it will be grilled at 350 degrees for 50 per side everywhere on earth. To make the product you just follow the rules, to work for the franchise you must learn the rules and to manage a franchise you must enforce the rules.

The rules have been carefully designed by highly intelligent people so that most people can follow them with minimal training. The procedures include all kinds of fail-safes, like warnings to remind the cook to flip the burger. These are created to reduce their dependence on staff. The depth of the procedures is staggering. The system assures that your experience will be consistent. No matter where you go it will be like déjà vu all over again.

On the other hand, the savy consulting startup doesn’t follow an Operations Manual. They rely totally on high powered talent and experience. Having worked for both large established firms and startups I think it’s pretty obvious that the startup delivers better product than does a large firm. What many people don’t realize is that many large firms contract the work out to small boutique firms. It begs the question why can’t a big company with depth, scale, and cash not produce a great product?

The problem of course is scale. The common way of dealing with scalability is to hire junior staff, and give them precise instruction on how to run things. A simple recipe for producing consistently mediocre product.

The franchise model will not work for Thinknostic. ThinkWRAP will not enforce a standard approach but rather will encourage us to choose the best approach for the specific client and project. We will continue to hire top talent and focus our management attention on collaboration and innovation. Efficiencies will be realized through re-use and by crafting creative solutions to problems and proper project management practices will keep our projects on track.

The Thinknostic approach will be to build a strong team not a reliance on procedures. Every individual Thinknostic team member is an important member of our team. As a team, we compliment, inspire, motivate and support each other, resulting in a team whose aggregate is greater than the sum of its members.

Understanding your customer

Ever wonder why one project goes so well while another is challenged.  How is it that a particular approach work flawlessly one time and fails miserably the next.  How can same team using the same methods produce radically different results.  Could it have something to do with the customer?   

Projects often struggles because organizational culture clashes with the way we manage and perform projects. An operationally driven organization may have difficulty recognizing the value of   project management. As a result project management may be viewed as an unwanted or unnecessary overhead.  Anything that looks like it is adding work looks like a cost rather than a benefit. 

For a project-based organization, there is the understanding that projects are a core component of the business model but even in these organizations many executives view project management as being solely for project managers.  Executives and sponsors must play a key role in projects.  Decision making on projects requires an additional level of transparency and accountability. 

Having been a consultant for many years now I have had the opportunity to do project work for organizations in many different fields and of differing sizes and types.  I am beginning to understand how important it is to tailor your project management practices and to choose methods and plans that suit the character of the client organization. 

Super Hero

Are you looking for a team building exercise ?  Here is a quick, fun and free online service that asks you a series of questions and tells you which superhero you are most like.  Have your group or team visit the site and fill in the questionaire.  It will generate alot of conversation and that is always a good way for people to get to know each other.  It’s also good icebreaker. Here’s mine… 

Superman 80% The Flash 70% Green Lantern 65% Supergirl 60% Iron Man 60% Wonder Woman 55% Hulk 55% Spider-Man 50% Batman 50% Robin 50% Catwoman 35% You are mild-mannered, good, strong and you love to help others.

The Matrix

Being a Project Manager in a matrix organization means that you are responsible for delivering results that require cross-functional coordination and the collaboration of individuals who report simultaneously to you and a functional manager. The theory is sound, but in practice working in a matrix organization is a challenge. Project managers are pitted against functional managers in a tug-of-war over resources and the pursuit of what are often competing priorities.  Resources develop conflicting loyalties and are torn between two masters.

Stove pipe structures poorly serve the needs of businesses that try to operate projects. Creating successful projects requires not only the co-operation of cross-functional talents, but also the support of suppliers and contractors all of whom are critical to success, and none of whom show up at all on the org chart. So project managers are inserted and expected to manage a patchwork of a project team sewn from bits and pieces from across the organization. If we succeed it is not because of, but in spite of, the organizational structures that we operate within.

I have recently helped a department re-design it’s org structure to increase their agility.  They can now rapidly respond to quickly changing customer and business needs.  It was actually very easy to do, we just removed the silos and created a resource pools.  Staff love the opportunities they are now presented with and managers love the new degrees of freedom.

I don’t know why reconfigurable organizational structures are’nt more common place but I do know that they work and lend themselves to delivering successful projects.  Try it.

Begin Planning, with the end in mind

When Stephen Covey set out his 7 Rules for Highly Effective People, he offered this advice: Begin with the end in mind, also know as the habit of vision.  In summary Covey teaches us to work backwards from where you want to end up and make choices that will lead you there. This lesson applies to project planning and is particularly effective in Agile projects.

To apply the habit to planning I recommend that you engage your team in backwards planning by visualizing the desired end state with expected benefits fully realized and all features in place and then work backwards from there to define the sequence of deliverables required to achieve that goal.  Start by describing the completed solution with all the components and success criteria met. Get the team to list all the technical components and challanges that must be overcome to achieve that goal. Then moving backwards in time, brainstorm each successful step that must occur to produce the desired outcome. Ask the team to anticipate the roadblocks for each step and how they might best be overcome.

The real power of the exercise comes from visualizing success and making that image infectious by imprinting the final solution into the minds of all team members.  Armed with that image the team will anticipate the inevitable roadblocks and often have previously discussed how they may be overcome these obstacles. Backwards planning helps to prevent the team from getting “lost” where members loose sight of where they are in the project and what comes next. By starting at the end and visualizing all things that must be done to contribute to the success we increase the likelihood that we don’t overload a deliverable and will instead put everything in it’s proper place and in it’s own time. This practice is particularly effective on Agile projects because is fully engages the project team in the planning process while also exposing the team to the desired business solution before taking on the technical challenges.   

World class golfers, olympic athletes and top athletes from other sports have come to understand the power of visualization and many employ performance physiologists to help them with their “mental game”.  As project manager you can borow some of their techniques to help your team reach peak performance. 

Are new PM skills required to manage Agile Projects ?

It’s safe to say that Agile projects are in some fundamental ways different from traditional projects.  Agile projects are more likely to adapt rather than control. Agile has release plans as opposed to an end to end plan.  Agile projects also tend to embrace the concept of self organization.

In traditional projects, the project manager directs and manages the team by assigning tasks, tracking deliverables and maintaining an up to date plan. The management style is often characterized as “command and control” and are often accompanied by higher degrees of formality.

Agile projects on the other hand encourage the collective participation of the full team for planning, tracking, and providing status. The management style of the project manager might be best characterized as facilitator or leader.  The Project Managers primary responsibilities on an Agile project are to create an environment that is conducive to high productivity and to remove obstacles that prevent progress.

Project Leaders on agile projects rely on facilitation, issue management, problem solving, coaching, communication and collaboration skills and less on planning, scheduling, and directing skills because those responsibilities are shared by the team collectively.

I am currently working on a very large business system replacement project that is anything but agile.  While most of the project is organized in a very command and control style; our team is moving to a more collaborative and cross functional approach. Our team recently reorganized to allow individuals to determine what subject areas or technologies they will focus on, and to agree on approaches to adopt to perform work.  As new work emerges we will form teams to select the approach, plan the work and deliver. My responsibilities are to clear any obstacles that prevent the team members from being productive and block distractions from the team wherever possible.

This approach increases our ability to adapt to the very fluid environment on the project in terms of scope and focus of efforts.  We are working with new technolgies are are hoping that this will allow us to quickly respond when we find better ways to get things done.  

I am convinced that you can successfully use an agile style leadership approach on traditional projects.  Despite having no first hand experience with it I am equally convinced that you cannot use a command and control style of management on an agile project.

So to answer the question I would say that the set of skills used to manage projects is the same regardless of whether the project is traditional or agile in nature. Where the difference lies is in the importance that particular skills and tools have.  This very likely means that not all traditional project managers will make good agile project managers (and vice versa).  The characteristics of the particular project, the project team,and the project environment will dictate what project management style is required.

New Recipe(s) for Software

Malcolm Gladwell’s talk on spaghetti sauce got me thinking about things that are wrong about software development.  In his talk Malcom describes an epiphany that led to a revolution in the way the world thinks about spaghetti sauce, and most other consumer products for that matter. He describes the process that led to the realization that the pursuit of the perfect spaghetti sauce was pointless because what we really want are spaghetti sauces. We want choice. We want chunky, garlic, vegetarian, mushroom, meatball and so on and so on.

We take this for granted today but in the not so distant past this represented a paradigm shift if the way we thought about product development and it explains how it has come to pass that our grocery store shelves are lined with dozens of varieties of spaghetti sauces. The principle applies to a very wide variety of consumer products; colas, crackers, shoes, tires, electronics. One industry remains for the most part unaffected by the consumers desire for choice ?  Software.  With the possible exception of accounting system we don’t seem to get it yet or if we do we don’t know how to do it.

What Malcom’s story teaches us is that we don’t need a better spreadsheet tool. We know that most of us use only a small percentage of the features we already have. We also know what few of us use the same set of features. What would happen if we grouped spreadsheet users by the product features they most often use. Would we see alignment by profession, job type or style. Perhaps what we need is specialty versions for accountants, for managers, for engineers etc… Would the features be dramatically different from on version to the other. Not likely, rather I think the presentation of those features would differ by emphasizing and making more available the features that are most commonly used. The bottom line effect as Malcom’s talk teaches us is that the consumer would be delighted and the perceived value of the product would increase. An when you consider that 20 years ago Spaghetti sauce sold for about $2 compared to $5-$7 today and also consider that sales of Spaghetti sauce has increased by orders of magnitude you begin to see a compelling business case to begin applying this principle to software.

I have used spreadsheets to illustrate my point but the principle could be applied to a very wide variety of software products including: Word processors, Drawing tools, CAD, GIS, Contact management. Virtually any shrink wrap software product stands to benefit. 

I said earlier that software companies just don’t seem to get it but there are exceptions. One of our customers develops Biometric systems for authentication and related functions. They develop commercial products and are successful at bringing these to market. By listening and working with their customers they have also realized that their customers are using their products in many different ways. As all good companies do they are responding by developing new features and APIs. They have also recognized the opportunity to create specializations of their products that allow them deeper penetration into specific markets and have engaged us to help them with that.  They have realized that it is better to ThinkWrap than ShrinkWrap.

Multi-Heritageism

Today the Thinknostic project team celebrated Diwali.  In India Diwali is a 5 day festival that celebrates life and hope for mankind.  Known as the festival of lights the 5 day festival features fireworks, great food and the strengthening of relationships. I am not from India, in fact only one member of our team is.  But that did not matter to the twelve of us as we took a mid-afternoon break and gathered outdoors in a rain shelter on a cold, windy and wet fall day to light sparklers and enjoy a snack together.  It was wonderful ! 

I was reminded once again of the many heritages that make up our team.  We have representation from many nations, several continents, both genders, a few religions, perhaps a dozen languages, different eye, hair and skin color, many points of view as well as varying heights and weights.  It’s a veritable United Nations except that unlike the UN we work very well together.  As individuals we may represent many different heritages but as a team we are building a single workplace culture.  It will be fun to watch it develop.

 

Happy Diwali.  

Lost in translation

When staffing a software development team we most often evaluate their knowledge of frameworks, languages and tools, as well as their ability to craft an elegant user interface, sensible data structures or complex algorithms. I recognize and appreciate that a software development team must have a command of these disciplines as well as the technologies it applies to software the problem. But I also think that what separates the good team from the great team is the degree of understanding that the team has in their customer’s business domain, the problem at hand and the expected benefits that the software is expected to address.  This is demonstrated by curiosity about the business, its processes, regulations, culture, competition and other challenges.  

An important aspect of this customer empathy is the ability to collaborate with domain experts. I believe that detailed knowledge of the business, the problem and the expected benefits is a vitally important thing for programmers to have. That knowledge will directly translate into a system is designed to solve the problem and a system that is easier to implement.  Critical to achieving this is the ability to collaborate with those that have the knowledge.

Old school software methodologies execute a series of translations.  A problem is translated into a business case, the business case becomes a requirements document, the requirements document becomes a functional spec, the functional spec becomes a technical design and that is finally translated into a working system.  Each of these transformations is performed by a specialist; business analyst, system analyist, technical analysit, DBA and developer.  Like the the old game of “Telephone” something is lost, and sometimes something is gained in all of these translations.  In these projects the developer is so far removed from the business problem that it’s no wonder that most projects fail to meet expectations.

When I look at Agile I see a method that fosters the development of customer/developer empathy.  These team members work closely with domain people to describe what the system must do and there is an opportunity for the developers to understand why it must do it. Armed with that knowledge the developers can make better informed decisions at every stage of the project.  From my experience this reduces the number of poor assumptions and avoids downstream errors that lead to rework or a system that is difficult to implement.  

One of the keys to success in building business systems is figuring out what meaningful contribution the software can do to strengthen the business. You need both good technical and business knowledge to achieve that.  You also need methods that encourage all team members to understand why they are writing the software.

Secret Sauce

What intrigues me most about Thinknostic is ThinkWrap.  I have used many good software development methodologies and found that none are perfectly suited for every customer and every project.  There are many projects today that are using adapted, hybrid (or scaled) versions of RUP or agile methodologies with varying degrees of inconsistent success.  Even though there are many great tools to support these methodologies many projects are struggling to figure out what’s really needed and what is not.  Often what works in one situation does not work at all in the next..

ThinkWrap is being developed with the recognition that each and every customer and customer project is in many ways unique.   Every customer has a set of organizational attributes that directly influence the nature of their interaction with a project.  Similarly each project has an equally intricate set of attributes that must be taken into account.  The genius of ThinkWrap will be a comprehensive and systematic process of assessing customer and project attributes and taking these into account to develop an approach that fits the situation.  Not the other way around.

I think it was Aristotle who first said that “excellence is not a singular act, but a habit”.  Years later basketball star Shaquille O’neil popularized that quote, declaring that he wanted to be known as the Big Aristotle.  I am not worthy of any association with either of these men but the quote perfectly encapsulates the underpinning  philosophy of ThinkWrap.  ThinkWrap describes software delivery, a quality program and project management.  It’s all of those and more but more importantly it’s the wisdom to know how to use them.