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.
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.
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