Tag Archives: Process

Please Stand-by to be Processed


Let’s begin with a quote from Alistair Cockburn, one of the initiators of the Agile movement in software development.

‘While a good process can’t assure delivery, and a good team can deliver despite an unwieldy process, a poor process can get in the way quite neatly’.

In case you haven’t figured it out by now, this post is about process. What it is. What it isn’t. Common misconceptions. Benefits. Implementation strategies.

What is a Process?

An established, step-by-step way of doing things, and a well-articulated set of internal and external documents and tools supporting it.

This is, of course, one definition of any number that may be out there. Another, more succinct definition (of sorts) that I’ve heard used is, ‘applied common sense’.

What isn’t a Process?

Magic. A silver bullet. A panacea. As the first quote above notes, a good process can’t assure delivery. That said, it’s a place to start. A baseline from which to begin and to continuously improve from. Even for the Agile purists that declare as part of their Agile Manifesto to value ‘Individuals and interactions over processes and tools’, are in fact rather processes driven in their own way through adherence to Agile processes and practices such as user story modeling , iterative development and time-boxing.

Preferred methodology aside, we could all benefit from a little bit of process – though not everyone is convinced.

Common Myths Associated with Process

  • Adds unnecessary steps and time
  • A form of micro-managment
  • Adds documentation for documentation’s sake
  • Limits creativity
  • Limits flexibility

These are common reasons why establishing (and documenting where appropriate) processes on a team or within an organization is often met with resistance.

On the other side of the coin, having a solid process that is understood, documented and followed can truly be the difference between success and failure on a project. And while it may not always be readily apparent from the outset, process can have numerous benefits for everyone involved. Here are 10+ that come to mind.

Benefits of Process

  1. Repeatable. Predictable. Manageable. Having a process in place will help to ensure that your delivery process is repeatable, predictable and manageable which has obvious associated benefits – as well as others explored in the subsequent points.
  2. Maximized efficiency. Minimized waste. To be able to hit the ground running on the actual work to be done vs. spending time defining the steps (the ‘how) and/or the creation of templates/documents/assets etc. to facilitate the work.
  3. Clear expectations. So everyone knows what they need to do, what everyone else needs to do, and what the timing and dependencies are.
  4. Reduces risk. By having processes in place related to the risky areas of delivery, risks are identified and mitigated early.
  5. Reduced re-work. With risks and/or issues caught earlier, the likelihood of costly re-work is reduced.
  6. Better quality product. With risks and/or issues caught earlier and the ‘how’ figured out in advance, the time and energy on the project can be focused on developing and testing the product, and the results will show.
  7. Reduced interruptions. Increased focus. Increased productivity. If there are still any skeptics, hopefully this one will help to convert them. While still having processes and steps in place related to the above points (e.g. risk identification and mitigation), an objective of any process should always be to provide more focused time for the team to do their work.
  8. Better awareness of the big picture. With a process in place and documented, everyone can see how their contributions fit into the larger picture.
  9. Cross training and professional growth. When processes are established and documented, it’s easy to train team members and new hires on how things are done to allow people to advance their career and not be ‘stuck’ having to take care of a certain task because he/she is the only one that knows how to do it.
  10. Increased customer satisfaction. Increased employee morale. With all of the above considered and addressed through the implementation of a process what works for your particular project/business unit/organization, the collective result will be increased customer satisfaction and increased employee morale, which is obviously good for everyone.

So now that we’ve seen the benefits of process, here are a few strategies for successful implementation.

Implementation Strategies

  • Alignment. When developing, documenting and improving your processes, take the time to step back and make sure it aligns with the goals and values of your organization, project and team members. Much like understanding how a work package or a test case maps back to a requirement in a delivery project, the way you get things done should also map back to individual, team and company goals.
  • Collaborate. Work collaboratively to develop your process with the people that will be using it. Seeking inputs from everyone will go a long way to ensure you have considered all of the areas and will also increase likelihood of adoption.
  • Don’t over analyze. While it’s important to not create a process in vacuum, not consulting and collecting inputs from all the stakeholders, be mindful of getting into analysis-paralysis mode trying to make it perfect for everyone. Take a page from the ‘Lean’ start-up playbook and seek to get your MVP (Minimum viable product) out there and then improve it over time.
  • Continuously improve. Further to the above point, processes should evolve and improve, so be active with looking for ways to make this happen. Process is not a one shot deal. Continuous improvement is key.
  • Understand that one size doesn’t fit all. Figure out what works for your team, your customer and your project and tailor accordingly. Consider having a step in the process to evaluate and tailor the process for each project, adjusting up or down based on factors such as the project’s size, type, technology and customer.

Leave a comment

Filed under Business, Business Analysis, General, Innovation, Management, People, Project Management, Strategy, Uncategorized

Broken Windows. Software. Process and Disorder.

broken window

Studies in the fields of criminology and urban decay have repeatedly found an interesting trigger mechanism – one that turns a clean and intact building, into a smashed and abandoned one. Care to hazard a guess what it could be?

A single broken window.

That single broken window, left unrepaired for a period of time has invariably lead to the rapid decline of the building and its community.

How does this happen?

It happens as a result of the sense of abandonment felt by those that live in and around the building; the sense that the powers that be don’t care about the building. So another window gets broken; then another. Later graffiti appears, followed by damage to the structure of the building. The spiral then continues until it gets to the point where the damage is beyond the building owner’s desire or willingness to fix it.

In one experiment in 1969, Stanford psychologist Philip Zimbardo arranged to have a car without license plates parked with its hood up in the Bronx, New York and another in Palo Alto California. In the New York example, vandals attacked the car within 10 minutes of its ‘abandonment’ and within 24 hours everything of any value had been taken. In California, the car sat untouched for more than a week. At this point Zimbardo himself smashed the windshield with a sledge hammer and then within minutes people passing by were joining in and then within a few hours the car was turned upside down and completely destroyed.

Social scientists Wilson and Kelling wrote about this ‘Broken Windows Theory’ in the March 1982 issue of ‘The Atlantic’. In this article they made these ‘inextricable linkages’ between disorder (or at least the perception of disorder) and crime. The New York vs. California example above – also referenced in the piece – notes how ‘untended property becomes fair game for people out for fun or plunder and even for people who ordinarily would not dream of doing such things and who probably consider themselves law-abiding’, and further, ‘vandalism can occur anywhere once communal barriers – the sense of mutual regard and the obligations of civility – are lowered by actions that seem to signal that “no one cares”’.

The Broken Windows theory has been credited in part for community based policing initiatives in various cities, perhaps most notably in New York City under the leadership of Rudolph Giuliani in the 1990s, where the focus was put on small crimes (e.g. vandalism, subway turn-style jumping) as a means of the prevention of larger crimes – by creating an atmosphere of order and lawfulness.

So, what does this have to do with software development?

Since the Broken Windows theory was theorized, software development teams have found inspiration in it, as a metaphor for focusing on the small things in order avoid larger problems down the road. Dealing with the ‘broken windows’, if you will, since ignoring them can result in ‘technical debt’ that will eventually have to be paid.

The idea is, that in addition to ensuring you’re doing all the right things – sweating the [seemingly] ‘small stuff’ – you’re not only developing a higher quality solution, you’re also creating an atmosphere on your project/team/company where process and quality matters. The Broken Windows theory as it applies to software development – generally speaking – asserts that issues should be dealt with before any further code is written. If the build doesn’t compile – fix it now. If there are bugs – fix them now. While this sounds simple enough, it’s not always the way it goes for one reason or another.

While each team and even each project for that matter will have different sets of processes for different reasons, there are still principles from this theory that can be used. Make it a point to agree on processes and standards for delivery. From unit tests, to comments and documentation, continuous integration and bug fixing – establish what your process and expected quality levels are and stick to them; even when you’re busy.

Especially when you’re busy.

In fact, ensure you’re working closely with whoever needs to be involved to make sure that you don’t find yourself constrained to the point where you’re unable to do all of these ‘little’ things, since that is a slippery slope to somewhere you don’t want to be.

I would further assert that this goes far beyond strategies related directly to the software development/coding aspect of solution delivery. Teams should also ensure that the overarching processes for solution delivery are agreed upon and maintained. While adherence to processes around things like communication, status reporting and risk analysis can sometimes seem like easy-pickings for corner cutting, the outcomes of doing so can lead you to a place where you could find yourself wondering how you got there.

One broken window at a time.

Reference: http://www.theatlantic.com/magazine/archive/1982/03/broken-windows/304465/

Leave a comment

Filed under General, Management, People, Project Management, Strategy

The Many Shapes of Project Management


If you’re at all familiar with Project Management, be it in an IT context or otherwise, or have the great fortune to have a Project Manager in your family or circle of friends, you may have heard of the ‘Triple Constraint’. Sometimes also referred to as the ‘Iron Triangle’ of Project Management, the Triple Constraint has been the de facto framework to illustrate the tradeoffs faced by Project Managers since the dawn of time.

With ‘scope’, ‘time’ and ‘cost’ as the 3 ‘constraints’, (with ‘quality’ often shown in the middle), the triangle metaphor is used to illustrate that a change on any one of these items will invariably result in an impact on one or more of the others. A couple of examples might include:

  • Adding a new feature or additional complexity to an existing feature (an addition to ‘scope’) will result in additional time and/or costs.
  • Delivering to an accelerated schedule (a change in ‘time’), you may need to add additional resources which will drive additional ‘costs’ (or require you to figure out areas of ‘scope’ that can be cut).
  • And on and on it goes.

While the traditional triple constraint/iron triangle provides the basic, ‘Project Management 101’ framework for managing projects, it of course doesn’t tell the whole story. What about risks and issues? What about client and stakeholder expectations? What about resource management and communications? And more…

Further to this – and thinking more broadly – what about things like ‘time to market’ of the product or service you are developing, or ‘adoption rate’ of the product or service. Do these things matter? Ultimately, the question is – in today’s environment, does delivering a project ‘on time’, ‘on schedule’, ‘on scope’, with an acceptable level of ‘quality’, make it a successful project?

As you might expect, there is some level of debate and discussion around this in the Project Management community. As such, the traditional Iron Triangle has given way to a number of derivatives of the original to try and incorporate some of the above noted shortcomings. Some of the many ‘shapes’ out there include hexagons, stars, parallelograms (the ‘Iron Parallelogram’ doesn’t roll off the tongue quite as easily as triangle) and more, but the one that seems to have gained the most traction is the ‘Project Management Diamond’ where ‘quality’ has been upgraded to an equal to the others and ‘expectations’ now sits in the middle.


While the intention isn’t that the particular ‘shape’ capture every single thing that a Project Manager needs to balance (as that would certainly be an ugly shape), there are still a few factors that I would propose might be worthy of inclusion from my perspective.

Keeping with the triangle shape, I might propose an inverted triangle that overlays the original triangle, to augment what’s already in place in order to add some ‘real-life’ factors that tend to also factor into projects, since as most Project Managers would probably agree, if all they had to manage were ‘scope’, ‘time’ and ‘cost’ – what a wonderful world it would be!

double triangle

Before proceeding further I should note that the facets of this model are not ‘constraints’ on their own (in case that much wasn’t obvious), but rather, important and interrelated elements in project engagements; the constraint lies in the challenge Project Managers and teams have in managing all of the trade-offs, considering all of the interrelations at play.

Client Factors

When it comes to delivering ‘successful’ projects, there are a number of client factors that tend to not get reflected in the models and metaphors that we see in Project Management literature. A few of these things include – how well a client understands their own business process, in order to be able to articulate them to your team during the requirements phases, or how well resourced the client team is in order to meet deadlines that are dependencies for the success of your project (i.e. securing environments, performing user acceptance testing etc.).

Other important client factors include a client’s understanding and adherence to processes (that should be) outlined in project SOWs and charters that relate to scope and change management, as well as how well they plan and execute internal change management activities to ensure organizational and user buy-in and adoption.

Team Factors

Similar to the client factors noted above, there many team factors that are not often spelled out in detail in the PMBOK and other Project Management resources. A few such examples include – whether or not the team put forth to deliver the project has the necessary skillsets and experience on the platforms and technologies being used, or whether the team members have been allocated at a high enough percentage to actually deliver to the agreed upon schedule.

Another important team factor (quite arguably the most important factor) relates to the individuals that make up the team and what makes each of them tick. What tools and technologies do they prefer to work on? How do they like to work? Are they an introvert or an extravert? Are they motivated more by intrinsic or extrinsic factors? And how much control do Project Managers have over being able to provide the conditions to optimize the team’s performance and experience on the project?


When it comes to processes, how much is enough? How much is too much? What is the best way to ensure team members have autonomy over their work, while also providing them with a sufficient amount of support and resources to succeed?

Also, how best to balance the need to shelter the team from distractions so they can focus on their deliverables, with ensuring that they have had sufficient inputs into plans that they will be held accountable to, and with ensuring the Project Manager is armed with the inputs he or she needs to represent the team for status reporting and communications?

Other things to consider in the realm of process might be: how well does your process adapt to different project types, different technologies, cross-business unit engagements and remote/distributed team scenarios? There are no answers that will be right all of the time in all situations (but chime in if you have them and would like to share), but figuring out the right processes and right amount of rigor will always be a factor in your ability to deliver.

I’ll close with a quote from Alistair Cockburn – one of the founders of the Agile movement – related to process. ‘Process is indeed important. While a good process can’t assure delivery, and a good team can deliver despite an unwieldy process, a poor process can get in the way quite neatly’.

Leave a comment

Filed under Management, People, Project Management