Skip to main content

When working styles collide... and projects implode

We've all been there.

You're on a web-based project, and things are going well. At least, you think they are. The right people are selected for the appropriate functions, and everybody's clear on their roles.

You've got a designer, a developer, a project manager, and business stakeholders who are driving the requirements. You've got interlocked programs that tie in with your initiative, and you've got a fairly constrained budget to manage to.

The timeline is tight, but if everybody just does their job, you should make your dates.

The initial requirements are gathered, stakeholder expectations are set, and the first set of deliverables -- comps that define what the end product should (generally) look like -- is due.

But it doesn't get delivered. The comps seem stuck in a perpetual working state with the designer, as repeat revisions are created behind the scenes in consultation with other designers... out of sight of the other stakeholders and approvers.

A week passes, with a new date set.

Again, Design doesn't produce the collateral it's supposed to hand off, so the next phase can commence. Development is chomping at the bit, wanting to get going, so they can check in some code. They make recommendations for how the designs should be changed, and Design doesn't much care for their suggestions at all. Stakeholders are in the dark, and they're getting impatient, too. This is all costing them way too much money, with nothing to show for it.

Words are exchanged. Tempers flare. Fingers are pointed. It hasn't even been a month, and already the project date is at risk.

The team tries to regroup, replan... but after the designer checks with their boss, the comps still aren't ready. Another few weeks pass, and finally the design is available for review. Stakeholders take a look. It's not exactly what they specified, but they can live with it, under certain conditions. They suggest changes, based on their requirements.

But Design isn't having it. They want to go back to the drawing board, as the funding available for the project continues to be eaten up by repeat design iterations.

More words are exchanged. Conflict ignites. Escalations take place. People start placing bets on whether the project will ever launch at all.

What's going on?

Basically, team members are being true to their Praxes -- their unconscious working-styles-of-choice. But in the process, they're derailing the project timelines, as their Praxes are out of sync with the cycle of the project they're in.

CycloPraxis "maps" people's preferred working styles to different business cycles, with Authors (I also call them "Inventors"), Builders, Capitalizers, and Extenders being most comfortable working in businesses that are in the same cycle where they're comfortable.


The first praxis (Author/Inventor) is made up of a small percentage of people that are always having fresh new ideas. A smaller percentage of those idea people go on to champion those ideas year after year until they are proven correct.

A second group of people (Builders) seek challenging accomplishments around unsolved problems and see them through to completion with unwavering focus to task. This second praxis thrives upon gettingitdone, whatever ‘it’ is. Upon completion of ‘it’, they simply look for another assignment. [Builders] rarely [have] the original idea and if called upon to propose the new idea might struggle to muster the appropriate spontaneous creativity.

A third praxis (Capitalizers) – and by far the majority – thrives when there is predictability and a defined structure in which they contribute to the profitability or effective resource utilization of the business unit. They enjoy situations where their output is measured and often tied to pay. Key players are often making incremental improvements in processes, products, efficiencies, yield, and costs.

A fourth praxis (Extenders) enjoys work environments where they can apply their expert knowledge, solve the problems of customers, or engage in training. This last praxis creates lasting value with their contribution.
Source: CycloPraxis in the Business World
By Doug Johnson / doug_johnson@djhome.net / Version 7.4 / June 1, 2006

But just as people feel comfortable working in business conditions that match their praxis, they also feel comfortable "slotting" into certain phases of projects and product development. The four phases of invention, building, capitalizing, and extending also occur with projects (or products), and the more closely team members' activities align with the phase of the project they're in, the more productive a project will be.

Designers (Author/Inventor types) contribute best in the initial "invention" phase, when the earliest parameters of a project are being defined, and they can use all their creative juices in setting things in motion.

Developers (Builder types) contribute the most when the project is being built.

Business stakeholders (often Capitalizer types) want to see their funded projects come to fruition and get refined as time goes on.

And ultimately, Extender types, such as long-term sustaining/maintenance teams will take over to keep the lights on and run that part of the business.

When all praxes are consistent with the various project cycles, things get done. But when Builders start encroaching on Author/Inventor ideas... or Author/Inventors keep Builders from doing their jobs... you've got problems. Expensive problems, at that.

Of course, a person's CycloPraxis is often well-hidden from view. Our working styles and preferences come second nature to us, and we often have a heck of a time seeing them with a clear eye.  We're invested in these instinctive ways, and we also have difficulty understanding the whys and wherefores of how others work, as well.

But as many of us have experienced, these CycloPraxis disconnects can be costly. And learning to understand not only our own working styles, but also those of others, can go a long way towards fostering real teamwork... and keeping projects on schedule. And on budget.

Comments

Popular posts from this blog

An introduction to CycloPraxis

CycloPraxis identifies the natural working preferences of employees according to the lifecycle stage of a business. Much has been written about evolutionary stages of firms, disruptive technologies, new ventures, and high technology marketing, but it seems that large firms continue to experience difficulty in deploying the necessary new products and opening new markets necessary for tip line growth and employees continue to wind up with assignments for which they are poorly suited. CycloPraxis explains this behavior and prescribes novel approaches. The classic match between worker and job is function: operations, manufacturing, marketing, finance, sales, development, etc. Certainly it is important to match job function to an individual's preferences. There is another equally important dimension to the fit between workers and their jobs: cyclopraxis. And there's more to it, yet. The concepts of Praxis can be applied all across the board. I came across this idea ...

Oh, look - another high tech mega-merger

Official: IBM to gobble Red Hat for $34bn – yes, the enterprise Linux biz Well, this is exciting. I came across this announcement this morning while I was on my regularly scheduled exercise bike ride. I get up every morning and get on the bike for a while, checking email and the news. And what news is more intriguing to me, than the blending of a massive, (relatively) ancient technology behemoth with a 25-year-old Open Source champion. From a CycloPraxis conjecture standpoint, it's a pretty tasty combination. I mean, here you have the classic corporate giant that's pretty squarely placed in the Capitalizing/Enduring "quadrant", acquiring a company that's always struck me as an innovator, and certainly reads like an Author/Inventor culture, liberally sprinkled with a good dose of Building. A Glassdoor review of Red Hat says : I have been working at Red Hat full-time (More than a year) Pros - Wonderful environment where your coworkers actually li...