More..."New Language of Project Work!"

It’s good that project and program managers have their own vocabulary, but to the outsider it’s all pretty dense and intimidating.  

Our purpose here is not to replace Google or Wikipedia, which provide extensive and (shall we say?) lengthy descriptions and definitions. Rather it is to provide a more succinct explanation of various project management terms, to explain some insider jargon that may be intended to obfuscate (who would do that?),  and to expand our project vocabulary of related techniques, all in a way that does not take the topic too seriously.

You can enjoy many more great "New Language of Project Work!" terms in our Language Gallery or visit our Blog Archive for a full listing of our blogs and project work terms.  Here are two of the latest terms we've added. Enjoy!

queuing theory.png

Queues – In IT development, the existence of queues creates significant waste. Queuing theory, which is not broadly applied in IT development, tells us that queues increase cycle time, expenses, variability and risk.  And long queues are worse. 
Despite proof that queues are the cause of much development waste, very few IT organizations measure queues in an effort to limit their impact or adopt methods that are proven to reduce queue impact.  While queuing theory is complicated, you should know that you can achieve productivity improvements and cost savings by measuring and improving periods of inactivity associated with queues.

QSM Study of Top Performing Projects – Do you need a little more evidence that smaller teams are more productive and efficient than larger ones?  Take a look at the study done by Quality Software Management: Top Performing Projects Use Small Teams. The results of the study demonstrated that smaller teams are dramatically more efficient than larger ones. Dramatically more.  
They examined a total of 564 information systems projects and divided the data into “small” teams (less than 5 people) and “large” teams (greater than 20 people).  To identify top and bottom performers, regression fits were conducted for effort and schedule vs. project size through a sample of nearly 600 medium and high confidence IT projects.  
To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. On average they found best-in-class projects delivered 5 times faster and used 15 times less effort than worst-in-class projects. Ok, there could be many factors that impacted this, including team talent.  But the characteristic that seemed most relevant was TEAM SIZE. The best-in-class projects teams were over 4 times smaller, on average than the worst performers.