In the technology sphere, architectural practices have contributed to everything from chip designs, to communication protocols to design and code repositories. Generally, things that receive architectural attention are of higher quality, cost less in the long term, perform better and receive higher levels of satisfaction from all stakeholders. But, is there an easy way of achieving those benefits on individual projects, of transforming projects with architecture?
In the following case, you’ll see how one organization used their architectural passion for slicing and dicing individual projects into their component parts, delivering better, faster and cheaper solutions while building reusable foundations for the enterprise.
Thanks to L.D. for the details on this story.
In this medium sized financial services organization, senior technology and business leaders from the four lines of business would often hang out at a local pub on Friday afternoons. The gatherings were informal and largely social. On any given Friday afternoon, the numbers could range from two or three to more than ten. On occasion, one of the business leaders would talk about a planned project and ask for advice from the other participants. Periodically, one of the technology leaders would chat about an emerging technology and look for feedback on potential opportunities and impacts.
Over time, the informal gatherings became a vital hub for advice and sharing. Often, instead of booking a meeting in the office to discuss a planned change, participants would confirm attendance at the Friday afternoon gathering. Depending on who was in attendance, the informal discussions often revealed multiple perspectives about the project that would have a beneficial impact on subsequent planning and delivery efforts.
The head of the database group, let’s call him John, saw what was happening with the Friday gatherings and thought there would be significant benefits in formalizing the process. So he sent out a proposal to the usual attendees and suggested it be discussed at the next Friday afternoon gathering, of course. Fifteen business and technology leaders showed up, including a number of first-time attendees invited by the regulars. They kicked the idea back and forth and managed to reach a consensus – let’s pitch it to the executives. John agreed to lead the effort.
The Friday afternoon pub group agreed to a target vision to accelerate project deliveries while reducing costs and improving development and operational quality. Their goal: a framework that would identify the business, information, application and technology components required to support a project that could be developed in parallel to accelerate one solution and be reused by others. They agreed to pursue approval of the following approach:
- Submit every project to a review by domain experts to identify opportunities, impacts, and shareable components.
- Use the review to partition the project into component parts, including business processes and functions, hardware, software and communication technology components, shareable code for business and technology objects and interfaces and components for human and technology consumers.
- Build the processes and facilities required to operate the review and launch exercise over time based on the individual project experiences.
- Above all, accelerate delivery, improve quality and deliver reusable components.
Essentially, every project could become a mini program with multiple businesses, object/data, technology and application components, built in parallel and assembled to deliver the final solution. The diagram below, initially sketched by John on a pub napkin and circulated to the attendees, became the official target.
John and a few of the other senior business and technology leaders from the Friday pub group took their idea to the CIO. He was a traditionalist with a computer operations background. They sold him on three key principles:
- Technologies were developing and expanding at an ever increasing rate. He agreed.
- The organization’s business lines would require support for many of these technologies because of customer demands. He was already experiencing that trend.
- Using priority business projects to assess a technology’s viability would address the needs of the individual projects while driving infrastructure capability to serve the entire organization. He loved the idea of the IT infrastructure being ready before the business needed it. He agreed.
John, the CIO and the business leaders from the Friday afternoon pub group took the idea to the executives, one at a time. They would have to buy in for the proposal to work. The agreement was reached one after one including the CEO. Then the real work began.
John and the other pub group members formed the initial review team:
- Corporate architecture – John (chair)
- Business lines
- Software development/delivery
- Project management
- Computer operations
There were some obvious knowledge gaps, particularly around the inter-relationships among the various points of view - for example, which business lines used which applications, objects/data, technology, etc. They decided to build their knowledge as they went.
The group started with the current year’s approved project portfolio. They sat down with the owners of the priority projects, explained the approach and asked for the owners’ support and participation. They then took the first ten projects through the process. Here’s what they discovered:
- The process was more difficult than it sounded.
- The group’s leaders found the process was taking considerable amounts of their time, so they started orienting and involving some of their senior staff to carry more of the load.
- Other than the broad generalities of their vision, they didn’t have metrics to help them gauge how they were doing and how the organization was benefiting.
- They found that some of the component initiatives launched to support a project were more expensive than the individual project could afford.
- On a couple of projects, they discovered that the total time and effort needed to deliver the identified component pieces would be significantly greater than what would be required to deliver the project in the traditional way.
- In a number of areas, they lacked the processes and methodologies to develop, deliver, test and operationalize reusable components.
The group’s progress and findings were communicated openly with senior management and project owners and received lots of attention at the Friday afternoon pub sessions. The group responded by tackling each issue as it arose. To tackle the issue of process complexity, they started focusing on the low hanging fruit. Yes, they left some potentially valuable reusable components on the table, but they delivered quality solutions quickly. To address the metrics gap, they started tracking components reused, the number of subprojects per project and elapsed time cut using actual time as a percentage of an initial estimate established by a subgroup of the team. They also started documenting the processes and practices that were adding value for future use.
Perhaps the biggest stumbling block the team encountered was on the cost front. They established another metric on total actual costs versus estimated cost, using as a proxy the expected benefit times required payback period. For example, if the estimated cost proxy was $750,000 (expected benefit of $1 million annually times required payback of 9 months), and the actual cost for all subprojects was $1.5 million, the total actual costs versus the proxy for estimated cost would be 2, or twice what it would have cost doing things the old fashioned way.
Obviously, they needed to get that number to 1 or less. However, in the short term, while they were building reusable components and not able to reuse a lot, they needed a mechanism to take a project’s business owner off the hook for the extra cost. The method they came up with was to establish a separate infrastructure investment fund that would pay for any extra costs above and beyond the estimated cost. The business leaders loved it. The company’s executives approved it and provided funding of $3 million annual for the first three years.
Over the first three years of this process, the results rewarded the company’s faith in the exercise:
- A number of components reused went from zero to an average of 26 per project.
- A number of subprojects per project went from 3 in the early days to 11 at the end of the third year, indicating much more parallel development was taking place.
- The elapsed time reduction went from 1.3 (more time) on the first few projects to .85 (less time) due to reuse and parallel development.
- Estimated cost versus actual cost went from 2.3 (significantly more expensive) to 1.2 (a bit more expensive). There was still some money left in the third year’s infrastructure investment fund at the end of the year.
Transforming projects with architecture!
Needless to say, all the stakeholders involved in this change were enthusiastic about the results. There were also other results which had not been anticipated. They discovered that breaking the projects up into their component pieces resulted in smaller, more predictable initiatives with fewer surprises and more reliable cost and timeline estimates. In spite of significantly more production change activity, production problems actually declined by more than 30% over the three years. As well, unforced staff turnover was down by 50%, and the annual employee satisfaction surveys showed record increases, mostly attributable to the emergence of an exciting, collaborative culture. Transforming culture with architecture!
How Great Leaders Delivered a Transformation
This change wouldn’t have happened without the weekly pub group. The participants were in a convivial environment, relaxed, and ready and willing to share some enjoyable chitchat, engage in wide-ranging discussions and give and take. It also wouldn’t have happened if someone, John in this case, hadn’t seen the germ of an idea and had the courage to shape it and present it to his group mates.
The actual practices presented here are difficult to apply on a project by project basis. Somewhat like project portfolio management, architecture needs some help from higher up the food chain. However, there are a few learnings from this case that any project manager or team can leverage:
- Share your ideas – Don’t hesitate to look for opportunities and share your observations. Let others contribute to shaping the vision.
- Take it outside of the office – Look for a relaxed venue outside of the office to exchange musings with friends and colleagues. A pub is a great venue but an off hours food court, a park, a walk around the block can also work.
- Embrace diversity – Don’t just hang out with the folks you normally encounter. If you’re in IT, engage with some business staff and vice versa. Include your boss, or your staff, or the boss’s boss. Include some customers. Be open to new perspectives, different ideas.
- Start small – John didn’t have all the answers, nor did the pub group, nor did the CIO or the executives. The germ of an idea was enough to get started.
- Break it up – The review team discovered that there were benefits to breaking projects into their component parts beyond the reusability opportunities, including better time and cost estimates, greater predictability, better quality and the opportunity for parallel development.
- Build proficiency incrementally – The review team could have taken six months to draft processes and procedures to help guide the way. Instead, they jumped in learning while doing and sought help when they ran into problems.
- It’s all about the journey, not the destination – All the stakeholders signed on to a journey of discovery. They didn’t know how much was in the pot of gold at the end of the rainbow. And it didn’t matter. They’re still on the journey.
So, be a Great Leader and put these points on your checklist of things to consider on your next project so you too can achieve great results. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors.
Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights.