People, Project Management, Requirements

Core versus Context on a Project

A presentation that is generating a lot of thought and discussion at Protegra is Geoffrey Moore’s presentation on the business of software. If you haven’t seen the presentation yet, you can find it at the following location:

Geoffrey Moore – The Business of Software

Although the presentation is primarily focused on Software Development and the innovation required to succeed at the business of Software Development, I wondered about how the concepts of Core and Context could apply to projects in general.

To provide a brief recap, when referring to Software Development these are the definitions proposed by Geoffrey Moore:

Core: Processes that differentiate your company for economic advantage.

Context: Everything else.

Project Value

I believe these concepts of Core and Context primarily revolve around client value. When discussing value for the Business of Software it usually involves increasing revenue for the company in question (Whom is the client). Even innovations are seen as a method to increase the number of clients and eventually revenue. How can we generalize the Core and Context definitions for a project? Here is one thought:

Core: Processes that implement the project for client advantage.

Context: Everything else.

Geoffrey Moore also discusses the concept of items to differentiate versus neutralize. I would propose in a project that both are Core, are required, and can be defined as follows:

Neutralize: To deliver the basic functionality and the project value as proposed and agreed to. Items that neutralize should be continuously evaluated as to whether they are good enough. Waste is defined as spending more time and effort that what is required to achieve the basic functionality.

Differentiate: To innovate to deliver more value than what was proposed and agreed to. Items that differentiate should always be the focus of innovation and never be deemed ‘good enough’. Waste is defined as not spending enough time to differentiate fully.

Two Observations

1. Context versus Core

The Core on the project is only what delivers client advantage. This would be code that implements business functionality, meets or exceeds the business need, and being actively used in production. Everything else is just context. This includes:

    • Project Management
    • Architecture (usually – depends on the project)
    • Infrastructure (usually – depends on the project)
    • Documentation
    • Testing

Geoffrey Moore also makes a point about knowing what to focus on and to what extent.  Additional effort and cost spent on Context will not return the value that spending that same time on Core will deliver.

2. Continuous Core Innovation

How often in our projects do we focus our efforts and innovation on Core versus Context? I think sometimes I have focused on Context rather than Core in past projects. I sheepishly recall that more of my ‘innovations’ on projects have been regarding project management, documentation, and testing. Context, Context, Context.

In some cases, I think we are almost more comfortable when we don’t have to innovate on Core on a project. Thoughts?

This should be a reminder that we always need to innovate and improve on Core. Not so much to add undue risk to the client, but unless we constantly innovate we are providing less than the maximum value to the client. And if we provide enhanced value to the client, we are certain to have more future projects and differentiate ourselves from the competition.


So do we drop all the Context work we are doing for a project? Absolutely not. Context and Core are both required on every project. These concepts do provide an interesting perspective on just being aware on how much Context we are doing in relation to Core. We should also ensure that we are innovating as much as possible on Core items at all times.

After all, Software Development is a business and if we don’t innovate to provide additional value, someone else will.

Re-posted from

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why


No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: