1. What Is Nolan Stages of Growth Model?
The Nolan Stages of Growth Model is an information technology maturity framework that describes how an organization’s use and management of IT tends to evolve over time. In plain terms, it helps leaders assess whether their technology environment is still experimental, growing faster than management discipline, or becoming integrated and strategically managed.
Consultants commonly use the model as a diagnostic tool. Rather than asking only, “What systems do we have?” it asks a more useful question: “What stage of IT evolution are we in, and what management practices do we now need?” For executives overseeing broader IT capability, that can be a helpful way to connect technology spending, governance, architecture, and business value.
Its enduring appeal is its simplicity. The model gives management teams a structured way to discuss why IT problems often change as the enterprise becomes more digital, more connected, and more dependent on shared data.
2. Origin and Background
The model is associated with Richard L. Nolan, a scholar of information systems and a longtime Harvard Business School professor. Nolan introduced a “stage hypothesis” for managing computer resources in the early 1970s, most notably in a 1973 Harvard Business Review article. In later work during the 1970s, the model was expanded and refined.
One important nuance is that sources do not always describe the model in exactly the same way. Some refer to the original four-stage version, while many textbooks and management summaries teach the later six-stage version. The six-stage version is the one most commonly cited today.
The framework was created to solve a practical executive problem: as computing spread through large organizations, IT budgets, applications, and user demand tended to grow in recognizable patterns, but management controls often lagged behind. Nolan’s model gave leaders a way to anticipate those shifts instead of reacting to them piecemeal. It became widely known through business schools, MIS literature, and decades of CIO and consulting practice.
3. How Nolan Stages of Growth Model Works
The core logic is straightforward: organizations do not usually move from limited computing to highly disciplined enterprise IT in one step. They pass through stages, and each stage brings a different mix of opportunities, risks, and management priorities. Rapid adoption creates complexity; complexity creates pressure for control; control creates the need for integration; integration creates the need to manage data and architecture as shared enterprise assets.
The model is best understood as a maturity path, not a rigid law of nature. Different business units can sit in different stages at the same time, and companies may move unevenly. Still, the sequence is useful because it highlights a common pattern: technology adoption tends to outrun governance before governance catches up.
The six commonly taught stages
| Stage | What it looks like | Main management challenge |
|---|---|---|
| Initiation | Early use of computers or digital tools, often for limited administrative or transactional tasks | Building basic understanding and proving value |
| Contagion | Technology use spreads quickly; departments want more systems, reports, and automation | Demand expands faster than discipline, standards, or budgets |
| Control | Management responds with tighter budgeting, project controls, standards, and oversight | Containing proliferation without choking off useful innovation |
| Integration | Attention shifts from standalone systems to cross-functional processes and shared platforms | Connecting systems and aligning technology with end-to-end business workflows |
| Data Administration | Data is treated as an enterprise resource, with common definitions, stewardship, and governance | Managing data quality, ownership, access, and consistency |
| Maturity | IT is managed as a strategic capability with disciplined planning, architecture, governance, and value tracking | Sustaining business alignment and continuous improvement |
What makes the model useful is not the labels themselves. It is the idea that different interventions are appropriate at different moments. A company in contagion typically needs governance and standards. A company in control may need to shift from local optimization to enterprise integration. A company moving toward maturity needs stronger architecture, shared data management, and closer linkage between business priorities and technology investment.
4. When to Use Nolan Stages of Growth Model
The model is most helpful when a leadership team senses that IT complexity has outgrown the way technology is being managed. Typical triggers include fast growth, acquisitions, ERP or CRM sprawl, overlapping SaaS tools, rising integration costs, weak data consistency, or repeated arguments about who owns technology decisions.
It is especially powerful in large and midsize enterprises, diversified businesses, and organizations that have accumulated systems over time. It also works well in settings where the question is not a narrow system selection, but a broader management issue: How mature is our IT function? Why are we feeling these pains now? What capabilities do we need next?
In practice, teams often use the model as an entry point to broader architecture assessment work, because stage diagnosis becomes most valuable when it informs concrete decisions about governance, integration, data ownership, platform choices, and operating model changes.
Useful inputs typically include IT spend trends, application inventories, project backlogs, governance documents, architecture standards, incident patterns, and interviews with business and technology leaders. A light-touch diagnostic can be done in one to two weeks; a robust enterprise assessment often takes four to eight weeks.
The model is less useful for very early-stage companies with simple technology stacks, for one-off product decisions, or for businesses where the units are so different that a single enterprise stage label becomes meaningless. It can also mislead if applied too literally. Modern cloud, product, and AI environments do not always move in a neat sequence, and companies can regress or jump ahead in some dimensions while lagging in others. Today, good practitioners use Nolan as a thinking aid, not as a deterministic prediction.
5. How to Apply Nolan Stages of Growth Model: Step-by-Step
Clarify the decision and scope. Start by defining the management question. Are you assessing the whole enterprise, one business unit, or a particular platform landscape? Be explicit about the time horizon and whether the goal is diagnosis, investment prioritization, governance redesign, or roadmap development.
Gather the required inputs and data. Collect both facts and perceptions: IT spend by category, number and age of applications, integration points, cloud usage, project demand, delivery performance, architecture standards, and stakeholder views on pain points. Interview business sponsors as well as IT leaders; stage diagnoses based only on the CIO’s perspective are often incomplete.
Define the units of analysis. Decide what you are rating. The whole company may be too coarse. In many organizations, infrastructure, customer-facing products, enterprise applications, and data management are at different levels of maturity. It is often better to assess a few major domains separately and then form an overall view.
Construct the stage assessment. Map observable evidence against the six stages. Look at application proliferation, budgeting discipline, governance mechanisms, degree of integration, data ownership, and business-IT alignment. Avoid scoring by intuition alone; document why each domain appears to be in a given stage.
Analyze transitions, not just labels. The richest insight usually lies in the transition point. Ask what tensions are showing up because the current management model no longer fits. For example, if demand for new tools is spreading faster than standards, you are likely moving from contagion to control. If separate systems now block cross-functional processes, you may be moving from control to integration.
Translate findings into operating choices. Convert the diagnosis into actions: governance changes, platform rationalization, integration priorities, data stewardship, funding mechanisms, and role definitions. This is often the point where formal enterprise architecture becomes essential, because the organization needs a target-state blueprint rather than another isolated fix.
Test sensitivities and alternative assumptions. Challenge the initial conclusion. Would the stage diagnosis change if you looked by business unit instead of enterprise-wide? Are pain points caused by maturity gaps, or simply by underinvestment, weak leadership, or a major post-merger transition? Test different cuts before locking in a narrative.
Align stakeholders and iterate. Socialize the findings with business leaders, product owners, architects, finance, and operations. Expect disagreement; that is useful. Refine the diagnosis until there is enough alignment to support specific priorities, accountabilities, and a sequenced roadmap.
6. Example: Nolan Stages of Growth Model in Action
The situation
A regional industrial distributor had grown through acquisitions and now operated with three ERPs, dozens of local applications, inconsistent customer data, and rising integration costs. Business leaders complained that simple cross-selling initiatives took months because systems did not talk to one another.
Why the model was chosen
The CIO did not need another inventory of systems; she needed a management diagnosis. The leadership team used Nolan’s model to determine whether the company’s problems came from poor execution or from a deeper mismatch between the maturity of the business and the way IT was being governed.
How it was applied
The team reviewed five years of IT spending, cataloged major applications, mapped critical interfaces, and interviewed leaders in sales, finance, supply chain, and IT. They assessed enterprise applications, data management, and governance separately rather than forcing a single score too early.
Insights and actions
The assessment showed that the company had moved beyond control but had not truly reached integration. Budgets were disciplined, but architecture standards were weak, business units still chose tools independently, and customer and product data lacked shared ownership. The result was a clear set of actions: create an integration roadmap, define enterprise data owners, standardize design principles, and launch focused solution architecture efforts for the highest-value process flows. Within a year, the company retired several redundant systems and materially reduced manual workarounds in order management.
7. Strengths and Limitations
Strengths
- Gives executives a simple language for discussing IT maturity.
- Helps explain why governance problems often emerge after rapid technology adoption.
- Links technology growth to management responses such as control, integration, and data stewardship.
- Useful for diagnosing enterprise-level issues, not just application-level problems.
- Encourages stage-appropriate action instead of generic “best practice” recommendations.
Limitations
- It can imply a tidy sequential path when real organizations evolve unevenly.
- Different functions may sit in different stages at the same time, which weakens a single enterprise label.
- The model is relatively static compared with modern cloud, agile, platform, and AI environments.
- It does not by itself tell you which applications, data domains, or capabilities to prioritize.
- Stage assessments can become subjective if the team lacks clear evidence.
8. Common Pitfalls and How to Avoid Them
- Forcing one enterprise label. What goes wrong: teams assign a single stage to the whole company too quickly. Why it matters: that hides major differences across domains. How to avoid it: assess key areas separately before forming an overall view.
- Treating the model as deterministic. What goes wrong: managers assume every organization must pass through the same sequence at the same pace. Why it matters: they miss the effects of acquisitions, regulation, or digital-native operating models. How to avoid it: use the model as a diagnostic lens, not a law.
- Confusing spending growth with maturity. What goes wrong: rising IT budgets are read as evidence of progress. Why it matters: more spend may simply reflect duplication or technical debt. How to avoid it: look at governance, integration, data quality, and business outcomes as well as spend.
- Ignoring the business side. What goes wrong: the assessment is run entirely within IT. Why it matters: maturity problems often show up first in customer, sales, finance, or operations processes. How to avoid it: include business stakeholders in interviews and workshops.
- Stopping at diagnosis. What goes wrong: the team agrees on the stage but does not convert that into actions. Why it matters: the exercise becomes descriptive rather than useful. How to avoid it: end with concrete choices on governance, architecture, data, funding, and roadmap.
- Using outdated evidence. What goes wrong: assessments rely on old inventories or last year’s org charts. Why it matters: technology estates change quickly. How to avoid it: refresh the fact base before drawing conclusions.
9. How Nolan Stages of Growth Model Relates to Other Frameworks
Nolan’s model sits in the broader family of maturity frameworks, but it is more managerial and enterprise-wide than many of the others. It tells you how the organization’s relationship with IT is evolving; it does not define detailed architecture methods or process controls.
Compared with CMMI and similar maturity models
CMMI focuses on the maturity of development and delivery processes. Nolan focuses on the growth of IT use, governance, and integration across the enterprise. If the question is “How disciplined is our engineering process?” use CMMI-style thinking. If the question is “Why is enterprise IT getting harder to manage as digital demand grows?” Nolan is often the better starting point.
Alongside TOGAF or Zachman
TOGAF and Zachman are architecture frameworks. Nolan is a diagnostic framework. A practical sequence is to use Nolan to understand why the enterprise now needs more integration or data discipline, then use architecture methods to design the target state.
With application portfolio analysis
Portfolio tools help prioritize what to retire, modernize, or invest in. Nolan helps explain why portfolio sprawl emerged in the first place and what governance model is needed so the problem does not simply recur.
10. Key Takeaways
- Nolan Stages of Growth Model is an IT maturity framework for understanding how technology management evolves as organizations digitize.
- It is best known in its six-stage form: initiation, contagion, control, integration, data administration, and maturity.
- Its main value is diagnostic: it helps leaders match governance, architecture, and data practices to the organization’s actual level of complexity.
- It is especially useful when IT demand, application sprawl, or integration pain has outgrown current management practices.
- Use it as a thinking aid, not a rigid sequence; modern organizations often show mixed maturity across domains.
11. FAQs About Nolan Stages of Growth Model
Is Nolan Stages of Growth Model still relevant today?
Yes, but mostly as a diagnostic lens rather than a literal stage-by-stage prediction. Modern enterprises use it to understand maturity gaps in governance, integration, and data management, especially in complex hybrid environments.
What is the difference between Nolan Stages of Growth Model and CMMI?
Nolan explains how enterprise IT management evolves as technology use expands. CMMI focuses more narrowly on the maturity and discipline of development and delivery processes. One is a broad management model; the other is a process improvement model.
Can small or early-stage companies use it?
They can, but usually in a simplified way. A smaller company may use the model to spot early signs of uncontrolled tool growth or unclear ownership, but it typically does not need a full enterprise-stage assessment.
How long does it typically take to apply in a real project?
A quick diagnostic can be done in one to two weeks if the scope is narrow and data is readily available. A full enterprise assessment with stakeholder interviews, architecture review, and roadmap implications usually takes four to eight weeks.
What data is needed to use the model well?
At minimum, you need a current view of major applications, technology spending, governance practices, and business pain points. The analysis becomes much stronger when you also have integration maps, delivery metrics, data ownership information, and interviews with both business and IT leaders.
