Project Intake and Congestion Collapse


Originally posted on LinkedIn here.

Recently, I was reminded of a computer networking concept called congestion collapse (or congestive collapse according to Wikipedia). The basic theory, which has been proven in practice, is that something counter-intuitive happens when the amount of data being sent reaches the limits of the network device and more requests are continuously made. The amount of data that can be processed does not flat line at the top of the curve, but instead it completely collapses (see my graph). 

This is an oversimplification, of course. Briefly, for the non-computer types in the audience, the network device referred to is usually a specific piece of hardware, such as a network router or switch. The data I refer to are TCP packets. The reason the useful work nosedives is that the network hardware starts to get overloaded once it reaches maximum capacity. It then starts dropping (forgetting) packets because it can neither process them nor store them in memory (in networking this is a full buffer or queue). The hardware starts then requesting that the packets be resent. This requires more processing power to make these requests and as the amount of requests come in for processing, it drops more, has to do more resubmit requests and starts being unable to send out packets it has not dropped. And so on…. Which leads to the amount of useful work collapses.

What does this have to do with project intake? In my experience, project based areas tend to stumble and fall under the strain of many, many requests. Generally, I see this in IT areas specifically as they are very project intensive with feature requests, break-fix work and a variety of major software / hardware installations. They start the year with a (relatively) clean slate of known project work that they need to manage. They make a plan to complete that work and it all looks great. Yet, as the year continues on, they begin to struggle, fall behind and get complaints of not being communicative. Why?

I believe that similar to a networking congestion collapse situation, a project team without an intake process or a centralized project portfolio management area, such as a PMO, will start to do things similar to that poor, helpless network device mentioned above. As the amount of work requests increase close to capacity, the team starts to spend more and more time on non-work tasks. Communication needs to increase as more people ask for updates, status, and to make changes, etc. As the team gets drawn into more and more project meetings for a wider variety of projects, mistakes get made and useful work declines.  The negative impact of more people requiring communication can be seen in Fred Brook’s classic work, The Mythical Man-Month. That impact from the group intercommunication formula alone can destroy productivity. 

Therefore, I think any project area requires some kind of intake process, gatekeeper or some kind of congestion control (again, another networking term). Intuitively I believe it makes sense, but I may explore the proofs around this in future posts. 

Business Continuity & Vendor Assessment – Tip #2 – You Have to Partner


Please find the second tip in my series on vendor assessment originally posted here on LinkedIn:

Text of the post below.

In the previous tip in this series on vendor assessment related to my upcoming presentation at DRJ Springworld 2017, I covered the basic idea that a business continuity practitioner must accept the fact that they just cannot assess every vendor. In large organizations, this is especially true. In this brief tip, I want to touch on another key to success to do this work on a shoestring budget.

Yes, as the tip title states, you have to partner with others in the organization. If you are lucky, you can partner with a centralized vendor management business unit or a legal department. If you are partially lucky, you can partner with various contracting / purchasing people throughout the organization. If you are unlucky, no one returns your calls!

Getting a partner in place may require some sales tactics. Try these:

  1. Generally, you are there to reduce risk to the organization and most partners want that as well.  Find that common ground.
  2. Assure the partner that the assessment of the vendor will be non-threatening and have minimal impact to any selection process timetable.
  3. Offer up data. As a potentially centralized point of information about all the business processes in the company, you can offer data on what vendors the various areas of the company are already using (if their business continuity plans are complete). This is a potential treasure trove of information for a centralized vendor management area!

As a side note, I want to emphasize sales tactic #3. This is good to keep in mind for just about anything you might need from any area in the organization. If you have at least some support from upper management, you will be accumulating valuable business process, systems, interaction and vendor information from everywhere in the organization. Do not underestimate the value of this!

Once you have a partner in place, you need to increase the speed of trust between the two of you. Offer them a road-map of how a basic assessment could be done and show them that you do NOT want to assess every vendor (see tip #1). Then, move on to tip #3… Create a non-threatening assessment questionnaire and show it to them. Now you have the potential to be able just have your partner hand the assessment to the vendor during the selection process with no impact to your own (shoestring) budget. What you do with the assessment comes later.

Business Continuity & Vendor Assessment – Tip #1 – You Can’t Assess All Vendors


For those of you interested in all things Business Continuity related, please check out my post (and hopefully series) on LinkedIn related to my upcoming presentation at DRJ Springworld 2017:

Kind Regards,