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.

Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.