To employ or not to employ, that is the architect staffing question

Blog post
edited by
Wiki Admin

Architecture has been a very interesting field to provide as a service. With the various changes in information products, data science, information technologies all building upon each other, its hard not to remain continuously engaged, amazed and curious.

There is the obvious reward of seeing your designs go live with the tangible solution. Web sites, data products, data centers, technology ordering, MIS, software, kiosks, sensors are things you can point at and say “we designed that”. Its a nice feeling. Maybe not as cool and tangible as a building, transportation network, trains, city centers, etc., but nonetheless, there is something exciting, sometimes intimidating about knowing your designs are being used for something real and for the greater good.

Its more of an internal, or dare we say even intrinsic reward, as from a management point of view, typically architecture buys back risk, achieves the expectations, and when all is well, it is a standing outcome that the typical the bulk of the recognition for success goes to the talented IT implementation team. That credit is seldomly connected to the value of the foresight and concepts that were the foundations of enablement of the project or program two or three years ago i.e. the right business model, the capital plan execution, the innovative operating concept, the team vetting and estimation selection. 

Yet, architects do get credit, when there is a “glitch” in the solution. It is not uncommon for that same team to assure the first thought after some cycles is faulty design flaws and the architect is back in the “credit” limelight and until solved or understood, is put right “under the bus”. For example, an airline client called years after the contract was over on several occasions. Once asking if we had broken or illegally used or infringed on patents (which was summarily dismissed); Another time during Y2K, when after 36 hours straight diagnosing the data center tested back-up VPN wire had simply “fallen out”; and finally, when one day prices on the web site sold international tickets for free plus fees, when it turned out it was the mainframe and happend many times, but historically travel agents intercepted the error on behalf of the mainframe.

But, nonetheless, in your portfolio of accomplishments, you can be very proud that you envisioned that concept, design, or solution. Point being, an architect naturally wants to see their design go live, and move onto the next design. Its not like an operations position where they become a master of efficiency in their trade. Or Development where they become an expert in a set of core technologies. Or a requirements or project manager who enjoys the battle of herding cats. An architect enjoys the conquest. They want to either keeping doing similar architectures or grow to the next.

The What is next? driver for architects

That being said, when a technical leader or hiring manager envision what concept is needed for instituting architecture services at their company, they’ll also need to consider, “what will the architect be doing after the next two projects?” as by this introduction, the drivers are very clear for architects in a career “what is next?”. 

  • Will they be churning out more architectures in same patterns, or growing the company, and thus their architecture skills will need to grow with it?
  • What will the role description look like after the first two projects – more technical prowess or more leadership and management growth?
  • What level of architecture services/work is needed against the size, maturity, and complexity of the organization? 
  • After the first two projects, what are the key results needed to measure a skillset that is both needed to have proven history and portfolio of work as well as handle future concepts against the description? 
  • How do you interview and commit for a role – do you assess portfolio for leadership potential or resume qualifications and in-basket technical exercises for the technical depth or both?
  • How do you measure creativity against portfolio trusting it is comparable while not asking too much hypotheticals as architects are built to design for the “what if” and they will beat you every time.
  • Do you know after the first two projects that you will have the challenge the architect will be seeking or that they can handle? 
  • Will it slow down and become a more technical hands-on position or will it speed up and the responsibility will grow, and can they grow with it. 
  • Meaning, what will the level of work look like – not just variable (fast/slow) or stable, but will the role description change or be static or limiting? 
  • Will you need them to take on any task that comes their way or be a strong expert in a specific architecture stack, but those tasks may have gaps in time?

This all said, these are the challenges or hiring a full-time architect. They will be driven by “what is next?” which if you do not know, then your likelihood for expected retention diminish before you start.

Retention and Sizing

Here are a few additional notes on architecture staffing we have encountered and followed by solutions on various staffing models for architects:

Its a buyers market for good architects. Good architects have grown their people leadership, change analysis, results-driven, and team-building skills. Good architects adapt to the subject matter and technical skills become, so that they can handle the rapid change in technology stacks, patterns – those aspects become like “the Matrix”, and they can see through the next technical vendor and industry wave of architecture stacks and grow their value through increasing ROI on services, outlining more valuable or efficient concepts of operation, and easily and collaboratively designing blueprints or transition roadmaps into the PMO change management plans. These positions will pay more, tend to have a lifespan of at most 3 years, and they will get bored. Now if you are hiring for a specific technology architect, then advertise for that and lead with that, in hopes that the stack has a reasonably lifespan and expect limited growth and know their role will be consistent repeat-ability on that stack and grow as only that stack grows and exists. 

Average architects will plateau. If you hired a technical or IT architect, it is more of an analyst or tech team lead architect. They will do this and do it well. If your company though is growing, and changing, and employing new technical stacks, new services and products and new or growing business models, your architect will not grow with it if they were hired as a technical specialist. The role changes from requiring just systems analysis or root cause analysis to business change, policy, or political analysis. The role will now required as the service or product grows in relevance and importance to the organization, a solutions, enterprise or chief architect who is needed that can speak business plan, total cost of ownership, product management roadmap, and present both up to C-level and lead technical teams. The IT or solution architect may struggle with hanging onto to old patterns they know, sticking with the custom portfolio, or worse yet, not keeping up with business management just-in-time training.The hardest part is as they are learning non-intuitive soft skills that go against the more IT introverted hard skill professional profile, they also need to keep up with keep up with the technical architecture changes induced by Moore’s Law and Metcalfe’s law. Typically, this becomes too much learning, and an external or new hire is required. In shorter terms, you wouldnt hire a cook and ask them to farm just because both work with food. This is why Technical architects overengineer as they move up – they do what they know as they move up. Vice Versa as well.

Position is needed for the next two projects, then what? Lets say the architect is brought on for specific architecture skillsets – maybe that is MVC stack flavor of the past few years or maybe that is enterprise architecture analysis – and lets say that architect is hired and is a perfect fit and model architect. As the first two projects wind-down, the problem is time has passed, Moore’s Law has changed, the portfolio requirements have adjusted, but the skillsets chosen may now becoming legacy. It happens that fast. Then, the architects adrenaline wears off from seeing the conquest of going live. They begin to realized the next architecture project is likely not to be a fit. They will tend to either know the end is near or hijack and get “proactive” as business is perceived to delay. As business looks at their next architecture need, data architecture, or process re-engineering, governance or in a new subject matter expertise, they consider if that technical specialist architect can morph.

The answer is technical or application architects do not tend to morph or grow with the organization. Then business considers a new architect, while retaining the old one. Now you have architect bloat, dual roles, and ROI on architecture is at risk of eroding. This is architectures achilles heel, which all comes back to the staffing model. Point being, hiring for the first two projects will yield an average architect, they likely will hit value stagnation, and either reduce into Senior Engineer role, which may be of value, but is definitely a compensation plateau, or they will realize their diminished value and either underperform or encourage them to move on which is just not a good way to acquire talent. Hiring a rock star externally out of the gate will work, but keep in mind they will expect compensation above the organization curve, above inflation, and they will keep up with the salary norms, even if they are comfortable with well-balanced life. They know they can move around to the next conquest.

The position is needed long-term as CIO trusted advisory, but near term, need hands-on technical architecture. Let’s say you instead start out with finding a seasoned trusted advisor, well experience in corporate culture, subject and domain matters, and familiar with patterns in enterprise, process, data, performance, service, technology, and security architectures as well as works well with the various change management domains. They are the perfect fit – except, starting out, you have a project that needs more than a guiding touch, but needs to get their hands dirty in new MongoDB and NoSQL map reduce code analysis. The seasoned veteran has not kept up with actually coding as they have been on higher order tasks, as they should. This gap between the role description long-term need, and short-term fiasco creates a perception of lower value of the individual, even though they were not hired to fill in these unique architecture technical deficiencies. Typically what happens here, is the junior technical staff will begrudgingly fill in the gap, wonder what the “old guy” is doing to earn such a salary, and take longer to team build. Technical architect will team build great with the team, but struggle antithetically with the upper levels, especially in handling the drivers, poltiical sensitivity, and explaining the benefits of the architecture, and design in simple speak. 

“The Bobs” –  As office space pointed out, when you bring in organizational development, or architects considering new implications to process, workforce, technology, and investment, there is going to be assumptions that the “short-timers” are in it to get the deliverable done, and get out, and not worry about the collateral damage. That is their performance driven job. They help the executive organize, see alternatives, model, get technical, management, and leadership expertise, and they are gone. As well, it tends to make any internal architects look bad, as they will be moving at a pace that makes the underlings and overlings ask – “why couldn’t you have done that?”. Now it gets the job done, but definitely is more of a clean-up technique than a bonding and corporate unity experience.

Alternative solution to “After the first two projects, what is next?”

Essentially we have pointed out some major challenges to hiring – but more importantly – to the architect as a full-time employee model?

  • How can you keep good talent? How can you retain the investment and knowledge?
  • Are you going to want the role to expand? 
  • How can you get both the architect who grows with the company and solving low-hanging fruit tactical hands-on issues?
  • Do you have enough work to keep the architect adding value based on what you are compensating for full-time employment?
  • How can the architect keep up with rapidly changing technical patterns as well as growing in leadership, management, enterprise context, and corporate subject matter?
  • How can you keep up with changing expertise while balancing the amount of change introduced to stay innovative, relevant, and moving towards stakeholder and stockholder end goals in a timely manner?

Simply put, the full-time employee for an architect position that is likely to grow with company or product will and does not work. That is too much change to ask of the architect – they have to lead change, train others in change, grow in 3-4 professional domains, all while still being interested in a company asking a lot out of them full knowing the rest of the market is buying back risk and innovation in this skill as well. Or they may be able to do it when the service footprint is small, or in project mode, but as soon as operations picks up, moves from a project to projects to program, to regional to division, on the fast ride of national or worldwide services, that is when the peter principle kicks in.

Point being, Consider other models based on where you are buying your risk

  • If you only need for next two projects, consider contract-based employee
  • If your organization is on roller coaster of growth and portfolio change, contract out consulting firms
  • If your organization has the raw talent, but need some temporary leadership, contract our consulting firm leaders to grow team
  • If you want long-term, but can’t define needs bring on consulting firm to bring in various architecture skillsets

Setup these external support (contract, independent consultants) to address 4 major things:

  • Make them earn your trust – setup a starter or bridge task – You need to connect with the individuals before you commit long-term. Give them initial tasks. Worst case, if you change your mind and want to go back to employee, you have flexibility now. Thereafter, award good work with next tasks, but appropriately longer. 
  • Be clear on what may change –  Don’t map out the roadmap for them – make them earn their purpose, but at same time, let them know what roles may be needed in future, so they have a sense of what type of architecture you may need. You wouldn’t hire a cook, then after six months after, ask if they could farm as well?
  • Define outputs – Try to avoid long-term time & materials. Maybe initially, but thereafter, be project or outcome milestone based to assure the honeymoon delivery value continues
  • Setup Lead Key Personnel – Make sure you get a team lead or lead point of contact you have written into contract/task order to escalate, report, and get status from to manage change, risk, issues, and quality. Though you typically do not get personal services contracts, unless it is just independent, you can ask for certain commitment level from A-team before they staff with a B-team – that is what you are paying for.
  • Contract Terms should be simple and clear – Clear outputs and due date from award, clear understanding of their assumptions for resources, access, team, and dependencies from you, clear either fixed price or not-to-exceed amounts, and clear indirect cost understanding (travel, other)
  • Know Executive expectations – If you know the executive is getting impatient, has high expectations, putting that on a new full-time employee may be hard. At same time, if you want to take time, build the culture, and internal skillset, building short-order  tasks to consultants will possible create adversarial relationships between employees and their bosses to show-off.

If an itch is being scratched, please take some time to review “What are Various Architecture Staffing Models” that Xentity can support.

What do current disruptive technologies mean to the roles of the Federal CIO office

Blog post
edited by
Matt Tricomi

We wanted to ask: What do current disruptive technologies mean to the roles of the Federal CIO office? 

Currently the Counter Weights are in Legacy footprints, primarily legacy policy

Traditionally, the operating model and funding approach for IT has been based on the Brooks Act of 1965 and only added minor portfolio integration concepts based on the Clinger-Cohen Act of 1996. These acts were focused on internal IT cost-based centers, management information systems, mission control systems, and enterprise resource planning systems. These systems were all either internal mission or data processing systems used to run business. Since 1996, a lot has happened in the IT based. It has moved from cost center to profit center in the private sector and in the government space to service or profit center as well (i.e. profit for IRS in efiling). As normally is the case when shifting positions of an asset to the executive level, this also means the investment models change and shift as it is now a critical part of executing transactions and interactions direct with the public, yet our policies are now 20-50 years old.

A few general observations :
  1. The Federal experiment with Clinger Cohen and Circular A-130 addressing the role of the CIO and Enterprise Architecture has not neared fulfilling its objective. New strategies such as CloudFirst and Federal Shared Services are guiding investment, but not new roles of CIOs.
  2. The policy and roles need to be readdressed to manage disruptive technologies like shared services, commoditized cloud computing, information exchange or data and knowledge driven analytics and “who-knows-what-else” coming down the line.  
  3. The CIO’s shop has not been able to transform to meet the basic demands of security and infrastructure disruptions let alone attempts to solve the needs of the mission.  
  4. Additionally, Enterprise Architecture is and has been miscast and ill-defined within the CIO organization and as a result is being used for compliance reporting or to support internal CIO initiatives leaving the mission out in the cold.  

If these statements are agreed to be true, Is it a wonder that a nearly a dozen years after the circular was published that people are still asking “What is Enterprise Architecture”?  Or does the Capital Planning & Investment Control (CPIC) process really lend itself to shared services? Are these skills and tools in the right organization?

Opportunities abound if the right people are managing the disruptions

The federal government opportunities for improvement are many but the most valued will be floating betwixt and between the current organizational, process and data architectures – in the federal architecture ether. 
This poses an especially difficult task to the business.  The mission leaders need to be allocating skilled resources to understanding how to assess the value of disruptive technologies or service changes to address their goals.    It is old school thinking that the CIO as a service provider can penetrate their mission problems with the timely and appropriate application of technology.  The development of extensible cloud computing platforms with transparent accounting systems provides an essential key for the mission to step in, reposition itself, and own the movement towards shared services, enhanced information exchanges or improved mission processes.  After all, they are the immediate beneficiaries.

What might these new roles look like?

What might this look like from a 100,000 foot perspective? In a Business Week article, it summarizes the new role of the Federal CIO, historically an IT manager, is now:

 In sum, the successful CIO needs an intimate idea of how current technology can increase the company’s sales and not just reduce costs or improve clerical productivity.

Beyond the CIO role, there are several other key leadership roles to consider in new, coordinated policy.

  • The future CIO role should be targeted to managing infrastructure services and support shared mission services. The CIO can retain the acronym but in essence they should be managers of cross cutting infrastructure and once agreed to and designed and built by the business – shared mission services.  
  • The Chief Architect provides the analysis and design expertise to the Program Managers and Chief Knowledge Officer to help plan for the adoption of the disruption.  
  • Ultimate accountability for performance will be the charge of the Chief Performance Officer.  

In order to achieve true business agility while supported by the adoption of disruptive technologies and services, these roles will need to be figured out how to be repositioned to improve the government’s business capabilities and satisfy citizens, businesses, and cross-government customers.

Fed Biz Solutions partners with Xentity Corporation

Blog post
edited by
Wiki Admin

Xentity Corporation (Xentity), a Colorado-based 8(a) certified business transformation consulting firm, and Fed Biz Solutions, Inc (FedBiz), a Colorado-based government compliance consulting and advisory firm, signed a partner agreement in November 2012 that enables Xentity to offer FedBiz services to customers

Xentity has integrated FedBiz service capabilities which help customers transform their business operations, alongside Xentity’s existing services that help transform customers’ mission operations. FedBiz now has the ability to offer services to customers under the SBA 8(a) Small Disadvantaged Business program and Xentity has additional trained staff to support FedBiz efforts and provides a greater blend of skilled government business specialists, better customer responsiveness. This also results in a blended price point to customers, without a reduction in quality. 

About Xentity Corporation:

Xentity (ZEN-ti-tee), founded in 2001, receiving 8(a) program status in 2010,  is located at the Golden Signature Centre in Golden, CO, assists commercial and government organizations, large and small helping to create true value via enterprise and solution architecture, planning, analysis and execution support. Xentity is a participant in the Small Business Administration 8(a) program and is a minority-owned disadvantaged small business. Xentity has helped clients achieve their business goals with management consulting and mission-driven architecture, while providing unique communication methods. Xentity has assisted Business and Government, large and small, in the executive trusted advisor role helping clients create true value via enterprise planning and execution support: from shortening emergency response at airports, or reducing college loan application time from months to minutes, to making hidden geospatial data into frontline services, or transforming previous policy information management groups to transformational world leading agencies.
 

About Fed Biz Solutions, Inc:

Fed Biz began operations in 1997 as Sterling Innovations, Inc.  The company has had very good success from the beginning thanks to the many wonderful clients who have shown continual trust in our consulting practices.  In 2011, the decision was made to expand the contract opportunities to include long term, federal Gov’t and large prime contractor contracts to help take the company to ‘the next level’.  One of the steps taken was to change the name to Fed Biz Solutions.  The name change was felt necessary to create a better awareness of the services offered.  Fed Biz Solutions was chosen because of its closeness to FedBizOpps (www.fedbizopps.com), the largest source for finding Federal Government opportunities.   For that reason, on January 1, 2012, the name change took place.  Fed Biz was the first step, but our team knew more than a name change would be needed to make a difference. 

The Surprising Reasons Why America Lost Its Ability To Compete

Blog post
edited by
Wiki Admin

Our Architecture Services Lead found this interesting Forbes article on “The Surprising Reasons Why America Lost Its Ability To Compete” written by several Harvard Business School MBA alumni. The article ultimately calls out management, not external factors as the reason for failure. 

 if there are disastrous shortfalls in the ability to compete, then surely the quality of management itself—the art and science of getting things done—must have a lot to do with it

Specifically, the focus on short-term and blaming external factors. At Xentity, we agree that though we understand management pressures in private and public sector have very impending issues to keep the organization within budget (public sector) and maintaining shareholder margins (private sector), but without and investment in outyear and next generation transformation, workforce, and research, the bailing water approach to management will not allow the organization to survive without adaptation. The article outlines:

  • Management trending to blame external factors instead of innovating, adapting, overcoming.
  • Management shifted to short-term focus and today’s numbers, versus investing in shared resources and pooling for longer haul
  • Managers have focused innovations and transformations more on cost-efficiency and cost-reductions and less on value-adding and increasing relevancy
    • Management education partly to blame focusing on short-term financial outcomes
    • Management shifted to focusing on maximizing shareholders outcomes while ignoring stakeholders needs
  • Instead of focusing on workforce/talent strategy, research, management instead continued focusing on short-term needs
  • Management can complain about government, external factors, but unless management finds way to not just focus on short-term needs, there is limited factors that government execution of new policies can do to stimulate growth
  • Management didn’t mention customer once in the report. C-level types have lost sight of understanding the communities of use, supply, and understanding their market
    • Management has lost ability to look back at the purpose of the program – to create the customer and balance with shareholder value

These observations from the study are very in-line with the Xentity’s published list of anti-patterns core architecture concepts towards view on transformation. As we published back in 2008, Our concepts are biased towards the next “generations” concept. The solutions recommended by the article generally align with our focuses on change as well:

Achieving continuous innovation and customer delight lies outside the performance envelope of firms that are built on hierarchical bureaucracy and focused on short-term gains and the stock price. It requires a fundamentally different way of leading and managing—in effect, a paradigm shift in management. It means:

Harvard Study: Management shiftsXentity Core concepts on addressing change

a shift from controlling individuals to self-organizing teams;

We are growing partners.

a shift from coordinating work by hierarchical bureaucracy to dynamic linking;

We think big on change, while changing small bits at a time

a shift from a preoccupation with economic value to an embrace of values that will grow the firm; and

We support executives transform their visions into action.

a shift from top-down communications to horizontal conversations.We share our concepts and supporting assets openly.

The article solutions wrap with balancing shareholder/budget-interests focus with stakeholder/relevancy focus:

 The article had some follow-on reads relating to this problem and emboldens many of the articles points:

And read also: 

In private and public sector, the management challenge is the same – external factors are continually battling against the mission, but management is doing the same thing to respond: Short-term cost-efficiency or cost-reduction approaches only with focus on the shareholder (private) or year-to-year budgeting (public). Management is not finding ways to balance the short-term and the long-term relevancy, and only education and leadership can help address, not waiting for external factors to make it easier.

What are some patterns or anti-patterns where architecture and governance can help

Blog post
added by
Wiki Admin

Architecture programs can be help to organizations – but for many different reasons. In same breath, by not identifying the needs for doing architecture, an architecture program can address problems that do not exist or leaders or team do not care about, and can become a waste of money or relegated to a compliance exercise.

At Xentity, we believe instituting architecture, governance or design guidance needs to address patterns, anti-patterns that create portfolio, solution and analysis management strategies that help deal with disruptions, investment in innovation, and shrinking budgets while improving services and aligning suppliers and partners.

Below are some example external pressure trends, common impact or anti-pattern trends cutting across cultural, business, and technology aspects of programs

  • Resistance to Change Planning: Intellectual approaches without balancing emotional or maturity context, not engaging leaders motives, pain, not seed-planting
  • Paving Cow Paths:  Automating management problems, function over form, not questioning assumptions, not looking at new (HR, IT, $) resource enablement patterns
  • Geek Speak Execs don’t get it, and its not their fault
  • Poor Modernization Blueprints: Mile-High, Inch-Deep, without proving pieces at time to gain momentum
  • Islands of Automation: aka Center of Universe – disparate sites, systems, apps, instead of services in user environment
  • Redundant Buying: Buying same item many times, no architecture  guidance to scale or change patterns

  • Program Management: Few delivered on time, on budget, on scope, on quality. Sponsorship lacking, not insuring/governing/buying risk, still not agile PM

  • Bad Data: Building GIGO Business Intelligence. Asking the wrong question of data which in turn leads to data collection failures.
  • Poor Cyber Security: IT security seen as lagging  IT cost, instead of asset-risk management issue
  • Too Much Change: Executives and Consultants promote constant flux, instead of unfreezing, adding change, and institutionalize new efforts and concepts
  • Problem seems insurmountable: Too large, complex leading to reversion to waterfall project planning techniques. The window for 2 years to test to new overhauling policies are gone. Business agility requires negotiation between business for prioritizing and agile project rollout.
  • Vision/Thought Leadership left to higher-ups only:  Challenging to staff to truly envision a change or target state not part of their incentive, even though best tactical ideas to enhance/meet strategy usually comes from within. Thinking gets bound up in current operational mire.
  • Revolving Door: Working to satisfy the management of today for organization political or self interest purposes. Middle management is often positioned or left to be soft with few exceptions on the drive needed to manage change. For example, with middle management and up are nearing or at retirement, large amounts started to retire, the churn caused by vacuum-effect at high level makes long term initiatives difficult to start or sustain.
  • Compliance Driven: Overwhelming amount of data calls with heavy-handed “fines”. Manage and plan to compliance – measuring to ineffectual measures
  • Compliance too complicated to understandCost/Price analysis on subcontractor costsSelf-monitoring/compliance reviews, manage contracting risks, methods and evidence used for estimation, understanding government acquisition regulations. Without expert help, small businesses are heavily limited to engaging.
  • Planning to the beast and not the customer: Fear at operational level of making decisions that lead to a innovative approaches or straying from norm – risk adverse. No reward for doing things better.
  • Delivering Value not part of Culture: Not sure of value of what we produce. no clarity on strategic outcomes and therefore have little recognition of recommended initiatives and what they mean to the workforce.
  • Blackbox Syndromes (aka Man behind the Curtain): Information Technology and management concepts and operations are overwhelmed by or shielded from the consumer of customer view. Programs/Mission are not informed of what IT has to do. Thus executive direction is disconnected, sometimes thus IT solutions or operations funding tie executives hands. Business agility gets put on backburner regardless of what Portfolio/Project Management is in place.
  • Surviving, not Thriving – Mission management model or system not designed to manage sustained change and transition. They are designed to deliver a product or service, if lucky.
  • Stovepiped Policy creates stovepipe programs: Cannot collaborate – need to get my task done now. Without collaboration, there is an inability for prioritization methods or techniques to be imparted and use effectively at all tiers of management.
  • Funding mismatch: Budget is a constraining variable in all work formulas precluding optimization across elements. These may be synthesied or aggrgated – mixed and matched as you see fit. Some programs may actually be funded right, but key functions of program budget are misaligned limiting what can be accomplished as a whole.
  • Enterprise Planning flavor of the day: Due to either past failures, or perception that new approaches are repackaged ways tried before kills internal buy-in towards integrated or collaborative techniques. Enterprise architecture, team functional/segment analysis, or agile project management may have been “tried” before, but instead of evaluating failure as tried to take on too much scope, other factors not resolved above, or simply, was over-engineered, are usually not labelled as the cause. The baby gets thrown out with the bath water or enterprise planning gets tossed aside due to lack of leadership, mistrust or burn-out.
  • Imbalance of Leadership Styles: Quick deciders, Stalling Stabilizers, Never-satisfied Challengers, Start-up Innovators – whatever the persona,  a lack of understanding of what each brings causes consternation or even over imbalance towards one style. Which leads to no decisions, status quo, low morale, or too much change.