Saturday, July 30, 2016

Patterns, practices, frameworks, and principles

As a solutions architect, I am often working on projects at various levels of management.  Depending on the level I am operating at, I will make use of, incorporate to, or help design frameworks, principles, patterns and practices.  Often, there seems to be a lot of confusion about exactly what the purpose of these constructs are.

Let's start with Principles. I think that simplicable has a really good definition of what principles are.  It states that principles are enduring rules and guidelines.

If you think about it, upper management uses principles all the time to help motivate staff and ensure that people are pulling in the same direction.  In management, these appear as mission statements, and corporate charters.
The goal of principles, in my mind, is to set the overall vision.  Akin to a core belief, principles help govern the frameworks, patterns, and practices that are used in an organization.  Further, principles give the nuance that guides how the other constructs are used in an organization.

Frameworks are essentially a set of principles and practices rolled together.  While it is true that the principles and practices may not be called out explicitly, the role of a framework is to provide an overview of a particular approach to achieve a specific objective.  It serves as a guide, and can be modified as required.

It is always important to remember that a framework requires implementation.  The implementation is not simply taking all the guidelines inside the framework and implementing, however.  It is the act of applying the framework, along with the principles of the organization, and determining the parts to modify and the parts to keep the same.

A framework that is implemented with no regard for the business context that it sits in can serve as a huge roadblock for future growth of that organization.  Alignment is crucial.

There has been a lot of talk these days about practices.  At least for me anyways.  I can't count the number of times that I have walked into an engagement where the client has asked for best practices.  If you have studied the cynefin framework at all, you'll have learned that best practices only exist when the task at hand is obvious or simple.

In any event, practices used in an organization, or for a project, will be derived from the framework being used, and be nuanced by the principles in play.  ITIL, for example, provides and leads to many practices.  However, if your organizations principles are that it is better to deliver something half-done then wait for something great, you'll modify the corresponding practices in use to comply.

Many people like practices, because they are the concrete implementation of the principles.  Think of it as answering the "how" question, whereas principles answer the "why" question.  Practices are great, but be careful of expecting a particular practice to define how to deal with every situation. 

Patterns, on the other hand, can best be defined as a general, reusable solution to a commonly occurring problem.  If you think about it, patterns could be seen as a construct within a framework, and could prescribe practices to follow given a particular situation.  I like to think of patterns as advice.  Not all of it fits my situation, some of it may require modification, and sometimes I can piece together advise from different people to form on my own solution. 

From an SA perspective, I find it very important to capture principles and frameworks as the start of my projects.  Getting guidance in those areas from the client help shape my solution, and provides some assurance that I will be focusing on the aspects that are important to the client.

Sunday, July 24, 2016

Some thoughts on delegation

Recently, I was being pretty nosy about a project that I was not directly involved in.  I was being nosy because I was genuinely curious about a particular aspect of their project.  After a lengthy chat about this particular aspect, one of the project team members sent me an email detailing what he had found and the options that were available.  After a couple of days, I met with the team again.  It turns out, this person was waiting for my input before proceeding.  This was totally a delegation fail, and got me thinking a lot about how delegation works in the real world.

First some theory.

According to this post there are 7 levels of delegation. 
  1. Tell:  You will do what I tell you to do
  2. Sell:  You will buy what I want you to buy (but it will be your choice)
  3. Consult:  I will ask you your opinion, wait for it, and then probably ignore you anyways
  4. Agree:  We will talk endlessly for hours until we agree
  5. Advise:  I will bestow my wisdom upon you
  6. Inquire: I will ask some questions about the decision you made
  7. Delegate: I will make you responsible
 The idea is that these levels work in both ways when considered from the different view points.  Further, these delegation terms are only to be used on key decision areas, rather than particular tasks.

Delegation happens more than we think

Most of the books/articles I have read on delegation describe this task as a concrete one.  Everyone knows we are doing "delegation" here because it has been explicitly stated at the outset of the conversation

I'd argue that, based on the theory above, almost every conversation we have with other people involves some form of delegation.  If my boss asks for my opinion on a particular area of the business, am I not in the advisory state?  Is this not some form of "micro" delegation?  If I am asking questions of another project team, to better understand decisions that are being made, am I not inquiring, and expecting the other team to sell?

While it might have been a function of my place in the corporate hierarchy, the example I provided at the start may help to prove my point.  In that example, i firmly believed i was "inquiring".  From the other view point, however, they were clearly in the "consult" level. 

I think that this model of delegation could be applied to more than just the traditional situations.  For example
  • Conversations between spouses / kids
  • Conversations between co-works
  • Conversations with sales professionals
In any event, being explicit about the level of response you are looking for in a conversation could go a long way.  In the example above, I should have been explicit that I was simply inquiring.  I want to understand why decisions were being made, not insert myself in the decision making process.

 The delegation process involves more than one state

I would say that delegation can't be seen in black and white terms.  When making a decision, people will often use multiple states depending on where they are in their own though process.

I'd say the most common one would work something like this

Consult --> Sell --> Tell

For example, my boss may consult me on a particular decision.  After consulting and coming up with a decision, they would probably try and sell it.  Failing the sale, the boss would probably just dictate the direction.  

While I think that I am violating the core principles outlined in the source article, I ultimately think that this is what happens in practice.  It might be a function of the hats that everyone wears.  

For example, let's say that a boss wants to "delegate" a particular decision.  They may do that, but then immediately enter into the "advise" state as a mentor.

The point I am trying to make is that while an overall task/situation/key decision area may be subject to a particular delegation state, individual interactions during that process may be subject to different delegation states.

 Delegation is an art, not a science

In his book, Management 3.0 the author provides a checklist for use in the delegation of tasks.  The checklist is a handy way of making sure that the delegation task is explicit, and that the person you are delegating to has the right level of authority to make an actual decision.  

I think that in practice, how delegation happens (and the degree to which it does) depends on the pair of actors involved.  

Ultimately, delegation combines many aspects together such as
  • Maturity of the team
  • Level of empowerment granted
  • Competence of everyone involved
  • Constraints on the decision being made
Coming up with a strategy that works for the team and the different members of that team is probably pretty difficult.  I'd ultimately err on the side of being more explicit than implicit.  Team that have worked together for a while may find that they are more implicit (regardless of if it works better or not).


Sunday, July 17, 2016

Iron Square of Constraints

If you have spent any time involved in projects and dealing with project managers, I'm sure you have heard of something called the "project management triangle".  If you haven't, here is a quick look.

This diagram is used to outline the constraints a project faces, and how they are related to each other.  It is common wisdom that you can't "control" all 3 of these constraints.  That is to say, if you want to fix the cost and the schedule, then you have to be flexible on the scope of the project.

There are many tools that can be used to measure/understand/control the various constraints above.


Cost is always an interesting one.  Generally, cost is measured as a function of money that is put in to creating the product.  For example, one would consider the resources being used on a project, the labour rates of those resources, and any additional costs (desks, licensing, etc).  Risks to the cost of a project are generally detailed as part of the risk register and reported up to the project stakeholders.

One thing that is often overlooked is the cost of NOT doing something.  For example, ROI on a particular workload may only be realized if the product is first to market.  Thus, a schedule that slips may have a significant cost implication above and beyond the cost of the resources on the project. 


Scope is generally defined as the requirements specified to achieve the end result.  If you are doing a good job of this, you are capturing both the functional AND non-functional requirements. 


This constraint is generally expressed as a "go-live" date or "target" date.  While it is understood that this should not be a completely arbitrary date, most end up being this way anyways.  In theory, this date should take into account cost/scope considerations. 


It is important to note that the concept of quality is muddled in the diagram above. Looking at it, you see that quality seems to be this thing that is made up of the combination of cost/scope/schedule.  It isn't quite understood that quality can be a target on it's own.

In the book, Management 3.0, the author describes his view on the "Iron Square of Constraints".

Talking about the constraints above as a gradient is truly a powerful tool.  Let me give an example.  It can be extremely difficult to build a application that is highly scalable.  It takes a lot of work to do this, and can add significant time to the project to build out completely.  For a proof of concept, or a limited release, project stakeholders may decide to forgo some of the quality aspects in favour for more functionality, or, less time/resources.

It also is a better visual to show trade-offs.  Given constrained resources and time, I have a choice to deliver many features with low quality, or fewer features with high quality.

This holds true for a mythical customer that wants to hold quality and time as constraints.

They would have the option of changing the resources assigned to the project, or fiddling with the amount of functionality that is delivered.

Later on in the book, the author discusses the "Escher cube of constraints".  It looks something like this.

While I think it is ultimately a more complete version of the constraints in play, this might be a little much to discuss with a customer during initial project discussions.