Managing Project Architectural Challenges

[Darin-Paton]

The original title was “Managing Projects Implementing Crap”… but I thought that was a little too harsh. It's reality and each organization will need to make difficult decisions as part of each implementation.…

Occasionally significant architectural principles/standards of an EA Strategic implementation, or related project, are sacrificed, even when architectural governance is in place.  Why?  In this series of blogs we will look at:

1. Some of the typical reasons and principles that are broken;
2. Try to understand why the decisions are made; and
3. How to manage and respond to the architectural issues that arise.

Some of the typical reasons and architecture principles that are violated

Having been part of many large enterprise projects since the early nineties I find that many businesses executing on their strategy through IT related programs or projects end up making decisions that compromise key architectural principles.  It begins during the project preparation phase when an estimate is delivered.  The typical large project estimating process follows a scheme similar to:

• 10 days for a very complex (i.e. Process, Report, Interface, Configuration, Enhancement…);
• 7 days for complex;
• 5 days for medium complexity; and
• 3 days for simple.

However, more often than not, the preparation and estimate seldom reflects the reality.   This ends up forcing the implementation teams, to make decisions that do not appropriately favour the architectural principles or standards. 

The three significant architectural principles I typically see violated across all architectural domains (process, application, data, and technology) are:

1. Lack of reusability – The solution will meet the immediate business requirement and scope of the project, however, when the solution needs to be extended it requires significant rework, if not a complete re-implementation.   
2. Solution is not operationally efficient – The requirement is implemented with many manual processes to support the end solution.
3. Lack of Sponsorship and/or Requirements – I can’t tell you how many “Build and they will come” and “Technology Drives Change” projects I have been part of and the majority of these implementations rarely end up being successful.  The technology ends up getting implemented, but the solution does not meet the business need and the business does not use the solution.

Now this does not mean there won't be exceptions and a process in place to manage those architecture exceptions.    I'm talking about architecture design/principles that are intentionally or unintentionally violated. 

In one case, having presented the architectural documentation to a small group of enterprise and solution architects they quickly realized there was no business engagement and all principles of a single architectural domain were violated.  This caused the project to step back and re-strategize its approach.

In another example, the developers for a solution were pressured to deliver on time rather than adhering to architectural reference models and design.  A quick internal project governance meeting was held to review the options and benefits to make a decision that was best suited to the company and stakeholders versus the project.  The developers were given more time to implement the solution the correct way.

There are examples, when suitable options and recommendations are presented to the Project Governance Council.  However, a decision is made to not embrace the recommendations made for various reasons.  Sometimes the decision does not even make it to the governance council.  In the next blog we will discuss why these issues arise and how to appropriately manage and respond as an enterprise/solution architect.

[stephenjohannes]

The problem is that for the majority of us out here we can only pick two of out of the three for most projects
- Time
- Cost
- Quality

In other words if you want something done fast at low cost you will end up sacrificing quality.  It would be nice to always deliver solutions that don't require re-work, and meet a design set of priniciples, but budget or timelines normally do not allow.

In addition "frameworks" take longer in general to build than "point solutions", and thus you put yourself when bidding on work at a disadvantage if your estimate is the framework solution instead of the point solution.

The last comment in estimating non-deep technical resources(project managers) are tasked with the job of asking technical resources how they can cut down the scope of the effort.  As the technical resource you are pressured to the spot solutions that don't always meet the guidelines.  If it really takes 10 days to do it the right way, then project resources should not be pressured to find alternative that only takes 5 days in order to cram 6 months of work into 3 months.

Finally, you should have kept the original title, much better IMHO.

Take care,

Stephen

[Darin-Paton]

Stephen,

Thanks for your reply.  You and I are getting a little ahead of the purpose of this blog, but that is OK.  Thanks for sharing.

The triangle to prioritize the project resources (Time, Cost, and Quality) is something that every project manager (OK I exaggerate a little) uses to set expectations with the stakeholders based on a certain set of criteria that the stakeholders agree to.  This can drive many of the architectural decisions that are made, especially if the Time and Cost are the priority, leaving quality a mute point.  And there are obviously some key business value statements in delivering in a specific time and with a specific budget. 


In the next blog I was planning to discuss that architects (Enterprise and solution) need to understand these constraints and be prepared to explain to the stakeholders the impact of the changes.  Things like how future enhancements or integration (if any) could drive costs and delivery time up.  And depending on the number of enhancements, the support SLAs may require longer to resolve due to the complexity.  If this is a truly a point solution with no future of Corporate integration… then the architecture governance team needs to let it slide. 

And your comment about frameworks taking longer than point solutions is true. However, if the business understands the limitations and constraints for future enhancements they may revise their priorities on the project resources thus supporting the project manager for more Time and/or Funds.  And I am the first to say that these don’t always go as planned, but as long as the stakeholders and governance team is OK with it then that’s fine.

A good comment on your estimating approach. I can remember being pressured to find a more compressed time to deliver something and it is unfortunate.  This is another reason that some sort of project governance needs to be in place to help others do the right thing (when it is in scope).  I truly believe that the majority of people desire to produce high quality output (That is good enough for the project in question).