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.
A Japanese word, describes detailed choreographed patterns of movements practiced repeatedly, either solo or in pairs. A kata is a karate technique where you repeat a specific form over and over and in each repeat, little improvements are made. An underlying presumption is that mastery of any skill results from persistent practicing - applying theory over and over again, identifying and learning incremental improvements and gaining feedback on results that can be applied to future practices.
A blog post by Dave Thomas brings this element of practice to software development professionals. He provides series of short (free!) exercise to practice certain skills. Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. The point of kata is NOT arriving at a correct answer. The point is the stuff you learn along the way. The goal is the practice, identifying small problems that can be improved, not the solution. PM professionals, project staff and management, how much are we practicing to improve our skills? Maybe we need a PM and project staff set of Kata exercises to do the same?
Kata is also used to describe an organizational culture, its routines of thinking and practice. One meaning of kata is, "a way to keep two things in sync or harmony with one another." It requires leaders and managers to create and maintain the organizational culture through consistent role modeling, teaching, and coaching. As project leaders, how much do we think about our organizational Kata?
HIPPO stands for “Highest Paid Person’s Opinion” – this is a type of project mistake that happens in hierarchical, top-down organizations where control and decision making is concentrated at the top of the organization. Decisions are not made by the most qualified person (that would be MQPO, certainly not as clever!) but are kicked up the line to a senior level person who probably has no qualifications to make such a decision. Most senior managers are generalists, they may have been specialists a long time ago, but no more.
Technical and project decisions are complex and should be made by the most knowledgeable person. Avoid HIPPO errors by pushing decision making downward to specialists. And hold the specialists accountable for the result.
See http://agilemanifesto.org. (It’s ok to click on this link, the Agile Manifesto (AM) is only 4 lines of text!) More a statement of values and organizational culture rather than a manifesto, AM was developed in 2001 by 16 developers who were seeking to explain their world view as to how systems and software should be developed. From the manifesto emerged several types of Agile methods, all of which share at least one common perspective, that is, that traditional IT waterfall development and bureaucratic corporate controls are the Anti-Christ. Pair programming, SAFe, FDD, SCRUM, XP, and more. Our view is the most important concept to arise out of the AM is the notion that working software should be the measure of the success of a system. Agile is easy to do on greenfield development, and much harder on brownfield.
"Perfect is the Enemy of the Good" - Voltaire
A philosophy and generally accepted truth that all project practitioners and managers should embrace. That is, that attainment of perfection is expensive, time consuming and not usually necessary. Project teams, especially those espousing lean development methods should value “good enough” over “perfect.” Time in development work is often the scarcest resource, and exchanging some minor areas of functionality or quality for fast completion is smart and often a good bargain.
"Cult of the Imperfect" - Watson-Watt
Sir Robert Watson-Watt, who developed early warning radar in Britain as a countermeasure to Luftwaffe bombing, advocated a concept called the "cult of the imperfect.” He described it as "Give them the third best to go on with; the second best comes too late, the best never comes." Also consider that achieving perfection may be impossible and so further activity beyond just “good” is increasingly inefficient and expensive.
In Scotland, a warning cry when it was customary to throw slops from the second story windows into the streets. A warning that something unpleasant was about to descend on one’s head. It would be good if project teams used such a term to warn each other of impending unpleasantness.
In IT development, this generally refers to managerial, technical and financial entities unconnected with any development organization team members. The evaluation of true independence requires an in-depth understanding of development and contractor teams contract relationships with other entities.
Technical debt is an IT “off balance sheet” item that explains what occurs whenever a development team takes short cuts and delivers code that is not quite up to standard for the organization. These types of trade-offs are often made in order to meet a ship or implementation date and may affect or relate to architecture, structure, duplication, test coverage, comments and documentation, potential bugs, complexity, coding practices and style. While these types of trade-offs happen pretty often, you should know that the technical debt incurred has a long term negative affect on productivity. And few organizations track how much technical debt is being incurred or how much has accumulated. A little debt speeds development so long as it is paid back promptly with refactoring. Time must be devoted on a regular basis to refactoring to the norm.
Intensity and Rigor
The level of V&V activity required for any IT project will vary based on the integrity level. Higher integrity levels require greater IV&V intensity and rigor. Translated, projects that are mission critical need more testing effort than those that are lower in priority. Intensity includes a greater or deeper scope of analysis, rigor includes more formal techniques and recoding procedures.
Based on the IEEE 1012-2012 standard as it relates to IV&V activities, it provides a method for managers to estimate the level and type of independent testing required for any given development effort. Integrity levels drive the level and detail of IV&V work, whether an IV&V team should perform testing, observe and review testing output, or take no action on testing activities.
Provides objective evidence for whether products conform to requirements, satisfy standards, practices, and conventions, have successfully completed the life cycle phase requirements, and meet the criteria for moving into the next lifecycle phase.
An old German word meaning "to go against," a synonym for counterclockwise or in a left-handed or contrary direction. It’s the last synonym we are after for its relevance to project work. Do you have team members who are always working in a direction that is not the team direction or consistently take a contrary position? The hard part is trying to figure out whether widdershins team members are right or wrong. Contrarians have their place.
After this post, everyone will know I am not a sailor. In late December as I write this, nautical twilight ends at 5:54 here in our geography. Astronomers and navigators have names for different phases of twilight based on the position of the Sun in relation to the horizon. Nautical twilight occurs when both the horizon and the brighter stars are visible in clear weather conditions, making it possible to navigate at sea. It reminds me that all projects have murky beginnings, times when it is difficult to see the path forward. But there is a time when issues become clearer and the path forward can be determined. And sometimes you just have to wait it out to get clarity.
This is a term that refers to an outdated or unreasonable position on an issue. For example, your project sponsor makes a major change to product requirements just before testing is to start and still wants his project finished on time.
Note the quotations, which may tip you off to what I am going to say. Ok, this is not really a project management word in the conventional sense. But in your quest to be persuasive as a project leader, never use this word. Drop it from your vocabulary. Why? Because it isn’t actually a word at all. Despite the fact that people have been using it for a couple of hundred years. And a lot of people who care about this sort of thing will tag you as uninformed and will be distracted by the fact that you don’t know this. When used, “irregardless” is always used to mean “regardless”. And “regardless” is a perfectly fine word…….
British slang, meaning “copious but meaningless talk or writing”. A late 16th-century alteration of “argue”. May be applied to project management status reporting that is of excessive length and that relies on the number of words in the report rather than the clarity and usefulness of the information. Or meetings with no purpose or agenda…..
Cost Performance Index (CPI)
Another project management term, CPI is a way to measure the cost efficiency of a project, based on the budget that has been allocated. To calculate it, you need several pieces of data (actual costs and earned value) and this data is not always readily available or accurate. Suffice to say, the CPI measures what you got for what you’ve spent. The CPI is also a measure of efficiency of your project team. If your project CPI is less than one, it means that you will probably have to allocate more funding to complete the scope of work. If it is 1.0 or higher, you are under budget. But beware of these types of calculations, they are only as good as the underlying data, which is seldom completely accurate. And it is only measuring against the project budget, which may or may not be realistic.
A planning method that attempts to match project tasks to the resources available to work on it. It is a technique used for schedule estimating. For example, if a task will require 320 hours to complete and there are two resources available for eight hours each day to work this task, the task duration will be 20 business days. Leveling ensures your resources are not overburdened beyond their capacity and leads to more realistic schedules.
A term used by chess players. Refers to a situation where any move you make worsens your current position. This certainly applies to project management. Consider staffing. If your project is behind and you add staff, your project will get further behind. If you don’t add staff, you lack the capacity to catch up and will stay behind. If the choices before you are poor, it is possible the circumstances will change if you wait a while. You do run the risk that you’ll lose momentum, and that is a substantial problem as well. But on occasion no action is the best action to take. Just not too often……
A knitting term, describing when a knitter is so frustrated with their work (wrong yarn, wrong pattern, wrong gauge, wrong tools, quality problems, wrong training….) they tear out some or all stitches and either start again or abandon the project altogether. To frog is to admit defeat with the current project and to move on to more productive efforts. An “aha” moment of clarity. An admission that the current path will not produce the desired result. In project management, there are moments of clarity that demand attention, so we can move on to more productive efforts. To frog is to findclarity.
Project Management Professional (PMP)
A certification held by several hundred thousand project management professionals worldwide, with about 350,000 in the US. Certified PM’s must understand the concepts of project management as defined in the Project Management Body of Knowledge (PMBOK), sit for and pass a 4 hour exam, and maintain certification through regular professional development. Its’s a good certification to have. It does not, however, tell you much about how experienced the PM may be, or how successful in past project work.
Also called Float. Slack is the amount of time that a task can slip before it causes a delay in completing the project. Slack is a good thing, it gives project teams some flexibility and time to deal with unexpected issues. Most good PM’s will build some slack into their schedules, without it, schedules are too rigid.
Rot, decay, putrefy, crumble, fester, molder, these are the synonyms for decompose, so it is no wonder this term is not understandable. Who on earth picked this word? In project terms, the word “decomposition” is usually bandied about during the planning process of developing a Work Breakdown Structure. What it means in this context is that project work is segmented into smaller and smaller pieces within the schedule so that tasks may be assigned to one owner and for a reasonably short period of time.
The owner part is so that we know who has accountability; the short period of time is so that once the project starts we can assess a task for completion without losing a lot of time if it has slipped. And what is a short period of time? Two weeks and 80 hours is a good starting point.
Work Breakdown Structure (WBS)
This is a project management planning method used to identify, assemble and organize all of the work tasks that will be necessary to complete the scope of the project. The work is organized in logical groupings. It is decomposed to a level that seems sensible to the project team and is planned at a level that progress can be measured in line with status report requirements. A WBS is usually completed before and as an input to the project schedule. There are lots of methods out there for developing a WBS, but the best one is a deliverables or product oriented WBS.
A term coined to describe the notion that all software development work runs on the edge of chaos and that the chaos cannot be controlled or planned out. Supporters of Agile development methods argue that the chaotic nature of software development suggests there is no point in planning software development projects or predicting outcomes. Of course, waterfall development advocates disagree. And business executives pretty much hate this as well……
(åsiktskorridor) Ok, I do not know how to pronounce this, but stay with me….
This is a Swedish term that literally translates to “the opinion corridor” and it is an expression that describes the boundaries (corridors) or limits of what is commonly acceptable for political discussion or debate.
Project teams everywhere suffer from this problem, topics that are perceived as off limits for discussion; regardless of how important the topic may be, when people rarely question the norms within the group. Often the social cost to the person of presenting an opposing view is too high. But in project work, you should work against this tendency. Remember that unresolved issues increase project risk and have a huge, detrimental impact on project performance. Get that stuff out into the open, regardless of the sensitivity.
Theory of Constraints
A manufacturing theory that is used to improve production throughput by identifying bottlenecks in production lines. Sometimes applied to management of Agile software projects. It says that a value chain (project) is only as strong as the weakest link in the chain. The capacity of the weakest link in the chain is the constraint. TOC is used by business systems that have accepted and learned to live with the uncertainty of software development.
In project work, a baseline is the original plan for how the work is to be completed. The project work is measured against the original estimate and any variances in execution are identified A baseline also serves as the starting point for change control, any change proposed to the original baseline are subject to formal change control and approval.
You probably know what this means, doing several things at the same time. But what you think is multi-tasking is really something else, called task-switching. And the research is pretty definitive that frequent task switching is bad for productivity, deep work, creativity and general health. Reduce task switching and see productivity improve!
Thank you to Mr. Mark Peters, author of “Bullxxxx - a lexicon” (New York: Three Rivers, 2015), 37-39, for digging this one up! Bumf is an abbreviation of bumfodder, and the literal meaning is: toilet paper. It has evolved as a reference to any printed matter that deserves to be crumpled and flushed away. It can refer to excessive amounts of paperwork, especially paperwork that’s considered useless or a hassle.
A famous Tar Heel and computer scientist, Frederick Brooks wrote “The Mythical Man Month” and said this about project work. “Adding people to a late project makes it later.”
This may not seem intuitive, but it has been generally accepted that the disruption caused by adding more people to a project increases the communications and training burdens on the existing team and decreases their productivity. New team members do not make up for the original team’s productivity loss, at least in the short or medium term. This is called the J-curve effect. The lesson here is that if you are going to add people to your project, add them really early so you have more time to work through the inevitable productivity loss.
This is extra money, generally budgeted as a percentage of the overall project with which to draw on should unexpected events occur. All projects should have some contingency reserves, but the amount varies a lot. The range is generally from 10-40%, usually based on the project risk, importance or level of uncertainty. Often, there are additional approval processes required for project teams to draw on contingency reserves, and this is a good practice too.
This is a project management technique used to shorten a schedule by adding resources and conducting some work in parallel rather than in sequence. It is only effective with experienced teams and when done early. Otherwise, it is rarely effective and not worth attempting.
Velocity is a measure of a team’s productivity rate to design, build, test and accept new releases, product or deliverables. It take a lot of work and accounting to do this well. It is also a capacity planning method that permits managers to forecast resource requirements for future work. If you are doing Agile, velocity is an important measure.