Flip a coin a hundred times and half the time it will come up heads and half the time it will come up tails. Project estimates (effort, time, and cost)?—well that’s a different story. Antidotal information is that project managers are more than five times as likely to underestimate effort, time, or cost than overestimate them. Why do we underestimate so often? Well, perhaps it is in our genes. If we ignore for the moment evolutionary biology, genetics, neuroscience, neuroepigenetics, phylogeny, phrenology, not to mention the Hardy–Weinberg principle, we see how underestimation is an evolutionary advantage for our species. How many times have you said that if you knew how hard it was going to be to do something you never would have undertaken it? If Thomas Edison knew how hard it would be to invent the light bulb would he have tried? Had the U.S. Congress known what the Webb telescope would eventually cost, would they have funded it? Underestimating is a tremendous advantage for our species, for it allows the creation/discovery of things that rational minds avoid.

However, while some evolutionary traits are an advantage for the species, they can be a disaster for the individuals of that species. For example, salmon swimming upstream to spawn is good for the salmon species, but the individual fish does not survive the journey. And the praying mantis who eats her mate—well let’s not even go there. Similarly, while underestimating might be essential for the human species to advance, it can play havoc for the individual, such as a project manager. 

The reality of the situation is that whatever you do, you might be destined, perhaps by some aberrant gene, to underestimate the effort required to build your system. This is the estimation conundrum. The systems development Kobayashi Maru. The no-win scenario.

There is only one practical workaround for this genetic peculiarity—feedback. The project manager needs frequent, timely, and accurate feedback as to the quantity and quality of all functionality produced along with the time and cost it took to produce it (See “Planning for the Perfect,” SD Times, March 2020). With constant feedback the project manager can finally overcome his or her genetic destiny. The number one source for understanding the scope of actual project deliverables and their costs is the post-project review (PPR).

The project’s PPR is a chapter in the project manager’s and IT’s history book. It provides necessary feedback so that the project manager can continually learn and improve project management skills. It can also be a valuable learning tool for other project managers, or would-be project managers, as to what to do, what not to do, and what to avoid like the plague.

The Internet is awash with PPR templates and sample reports free for downloading. You need only pick one and follow it. They all look a bit different, but the differences are largely unimportant if they include a traditional mathematical look at schedules, staff effort, costs, deliverables, etc. as well as two additional critical components. The first is lessons learned, a review of the project’s successes and failures. This section is the lynchpin for any hope for future project managers to learn from the experiences of those who went before them. The project manager should detail what worked, what didn’t work, and why. All subjects are fair game including tools, techniques, staff (user and IT), productivity, user availability, vendors, testing issues, working conditions (office space, technical resources, pizza delivery, etc.), and even those moments of brilliance as well as the mistakes made by the project manager. 

The second critical component is recommendations for future systems development projects, where the project manager speaks to future project managers (or his or her future self), detailing what future project managers should look for and what they should do differently. Think of Dear Abby giving lovelorn advice, only here the advice is for the managers of future projects.

However, this is only possible if a robust and truthful PPR exists. Many PPR tasks are included in initial project plans but they are eaten up by the two PPR enemies: poor project planning and scope creep. Once the project manager discovers that schedules or costs will likely overrun the plan, then the hunt is on for the tasks that can be sacrificed. The PPR is often the first. The 20-person day PPR is cut to 10 days, then five days, and then completely eliminated in an IT sleight-of-hand.

There are a few critical success factors for a good PPR.

1. Bundle the PPR into the Project Plan. The best way a project manager can increase the chances of a decent PPR is to bundle the review (including its schedules and costs) into the project plan. Some user managers might balk at paying for a PPR. Telling one user organization that they are being billed for a task that might only benefit another user organization is often a non-starter. If the PPR is a seamless part of IT’s development methodology, then it might very well pass user scrutiny. If it becomes an issue with user management, then the project champion might be useful in convincing the user of the value and importance of a robust PPR (See “Projects, Politics, and Champions,” SD Times, March 2022).

If user management refuses to fund the PPR then the project manager should encourage IT to foot the bill. It might take some selling (See “Half of Managing is Selling,” SD Times, November 2020) but if the project manager focuses on the benefits to IT, all might turn out well. If IT doesn’t have the funds to pay for the PPR directly, then IT might consider the cost of the PPR a project overhead item and bundle it into IT’s daily billing rate.

2. Positives and Negatives. This is not summer camp where every kid gets a trophy. Lay out what went well but also point out what could have been done better. Do not defend what is not defensible. If IT management failed to have needed developers or development tools available on time, say it. If user management never provided the promised space the team needed, say it. If the project manager miscalculated testing time, ‘fess up. (Don’t worry about retaliation. When was the last time a user or IT management voluntarily read a project team deliverable?)
3. Be Honest and Objective. There is no sense in going through the effort of a PPR if it becomes a puff piece (just the good things) or thin soup (a two-page Hallmark card congratulating the team). Remember all those times you went home frustrated and kicked the dog? This is the opportunity to explain those vet bills, cleanse the soul of the disappointments with being a systems developer, and help the next project’s team members with better canine relationships. 

Honesty is particularly needed in understanding project productivity. Accounting can give you an accurate “dollars spent” (cost) on the project, and HR the staff hours consumed (effort), both of which might be the only numbers that senior management cares about. However, for understanding productivity, both of these numbers are meaningless without also considering the work completed (the fully developed and tested functionality of the system). If functions were eliminated or their usefulness reduced, if testing was abbreviated, or if documentation was shortchanged, and these changes are not taken into account when calculating productivity, then a false number will emerge, the cycle of poor and inaccurate feedback will continue, and any hope of project managers learning from their experiences will evaporate. Ensure that the actual functionality delivered is the basis of any PPR.

4. Include Many Inputs and Many Comments From Many People. The PPR is not the project manager’s opportunity to settle scores. Every team member, IT and user, IT management and user management, should have the opportunity to add his or her comments and rants to the PPR. However, the PPR is not a social media blog. There should be an “official” opinion penned by the project manager. However, just as the U.S. Supreme Court might have a minority opinion accompanying the opinion of the majority, there should be an opportunity and place in the PPR for those who disagree with the project manager’s conclusions to post their opinion. 

There are four important PPR takeaways: 

1. Unless you are retiring after the current project, past projects can help you perfect your skills for future projects.
2. The PPR is the best vehicle for learning from past projects.
3. Use the PPR to build a picture of yourself as a project manager. (a) Where do you habitually underestimate or overestimate? (b) What should you have done differently? (c) What processes, data, or personal skills would help you be a better project manager?
4. Tell the truth—lying, shading, or coloring what really happened is a waste of precious project time.

Done properly the post-project review can be one of the most useful and most cost-effective tools in IT’s systems development arsenal. It will also please your dog.

George Tillmann is a retired programmer/analyst, project manager, and CIO. This article is adapted from his book, Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at georgetillmann@gmx.com. 

The post The Project Management Task You (Almost) Never Complete appeared first on SD Times.

Imagine your surprise when senior managers are not impressed. Hours spent color coding the work-breakdown structure wasted on an audience that does not appreciate the nuances of project management. To be fair, you might be bored at one of their presentations on RAROC (risk-adjusted return on capital), DSCR (debt service coverage ratio), or EBITDA (earnings before interest, taxes, depreciation, and amortization).

The reality is that each specialty has its own language, methods, and measurements that are often understandable only to the properly initiated. It makes sense, you would not trust your favorite Japanese chef to fly your plane or the pilot to prepare your fugu dinner. 

Worse, you might think that hearing all of that unintelligible-to-senior-user-management-geeky-jargon would make them realize that true IT experts are running their project. Not the case. You would probably be more effective reporting project progress through interpretative dance. Many senior managers consider jargon (at least not their jargon) a smokescreen hiding something you do not want them to know.

To effectively communicate, project managers need to see IT and the systems development process from the perspective of the user. Many users, including corporate senior management, do not understand what IT staff do and why they do what they do. They have a decent understanding of hardware—you need to buy it, you need to maintain it, you need to replace it. However, software and networks are seemingly unfathomable mysteries. You can see a computer; you can touch it; it has a physical presence, it is real. Software? It is intangible—who has ever seen it or touched it? It is not physical, so why do you need to fix something that is not physical—how can the non-physical break? Why does IT have people who dress like hippies (honest, who wears sandals in the winter?), smell like the homeless, (this is them talking, not me!), keep bizarre hours, and talk in a language unknown to anyone on this side of the Shire? And the costs! Why does something not real cost so much and take so long to develop?

They have a good point (except for the smell thing). They are competent and accomplished senior managers who know how to run their business. They might be experts in their respective fields, quoted in the Wall Street Journal or interviewed on CNBC. For them, IT is a very costly wizard shop of very expensive staff doing…who knows what. This uncertainty leads to many unanswered questions. Are the company’s IT people “the good ones” or are they the dregs of the profession? Are they working hard or treating the job like summer vacation? Are all those dollars spent on things the company really needs, and what is the deal with the pizza delivery bills? They simply don’t know.

It must be very uncomfortable for people who pride themselves of knowing exactly what is going on in their business to need IT to run critical parts of that business, to have it cost so much, to be overseen by such strange people, and to know so little about it. 

Yet, the need is mutual and symbiotic. IT needs the business just as much, if not more, than the business needs IT. Organizations have survived without IT, but no IT shop can survive without an organization behind it and willing to write all those checks. Therefore, it is incumbent on IT staff to adequately explain to business executives exactly why they are doing what they are doing, why it takes so long, and why it costs so much. IT staff who fail to learn this lesson might find themselves facing the Big-O (outsourcing), replacing them with consulting staff trained in business speak.

If you, the project manager, can’t present that RACI matrix and don’t know what RAROC is, then you have to do something else. You have to ask yourself, what does senior management want to learn from a meeting with the development team? What is it that will make them come away feeling that those in charge of their project know what they are doing and are working in the best interests of the company?

Hundreds of projects, thousands of project status meetings, and more than enough experience doing the wrong things, has taught successful project managers that, when all the dust has settled, management wants to know three things.

1. Is the project on schedule? Will the project end when is supposed to end?
2. Is the project on budget? Will the project cost what it was projected to cost?
3. Will it work? Will the system do what it was promised to do—features and quality?

Anything else is either gilding the lily or obfuscation. 

The challenge for the project manager is to adequately answer these three questions.

Less is More. Have you ever been to a really good PowerPoint presentation? Have you ever been to a really bad one? Content aside, one of the big differences between the good and the bad is the slide-to-minute ratio. 

Bad presentations contain a large number of slides in a short period of time. If your 30-minute presentation contains thirty slides (slide-to-minute ratio of 1:1) then the odds are high that few people will come away with a good picture of the project and/or a good impression of the presenter. The truly good presenters have a higher than 1:5 slide-to-minute ratio. Why? Because bad presenters get it backwards. They think that the presentation is the slides while their comments are the background. The truth is just the opposite. The primary means of communication at the meeting is the presenter speaking. The slides just underscore some of what is said. The successful presenter, and the successful project manager, must hobble together, not a series of charts and graphs, but a story—a story of how the project is doing. People remember stories—nobody remembers graphs. There is no greater take-away from this section than…

Project Management Review Rule One: A good presentation contains a good story that the audience can take with them when they leave. 

With this is mind, let’s look at the three senior management questions.

Is the Project on Schedule? Schedules are tricky. For senior management, some projects schedules are very important, while for others they are the least important answer to the three senior management questions (cost, time, and functionality). The difference is when the system is needed and the impact it has on the organization. For example, The Hershey Company, the chocolate manufacturer, required that IT have its new business-critical systems installed before the busy Halloween and Christmas seasons (when most orders are placed). Project schedule slippage (read the sidebar) caused mountains of unfilled orders and put the very existence of the company is jeopardy.

The best advice for any meeting with senior management is to know before you go. If schedules are non-critical to the user, then the project manager of a late project will probably get a pass. If, on the other hand, they are critical to the business, then considerable pre-presentation preparation, including possibly replanning, is needed. If the project manager doesn’t already know the importance of schedules to the user, the project champion (See “Projects, Politics, and Champions,” SD Times, March 2022) probably does. 

If the project manager is unsure of the business users’ tolerance for project lateness, then some pre-presentation homework is needed. The project manager should schedule interviews with a senior business manager or two to learn their allowance for lateness. Work on one or more possible solutions to the scheduling problem before the meeting—don’t show up without some options for remediating the problem. However, don’t postpone a meeting to avoid giving bad news. If there is bad news, it needs to come from the project manager and the sooner the better. Having management learn about it elsewhere can turn a bad situation into a disaster.

Project Management Review Rule Two: Do not present a problem without an accompanying well thought out solution.

This is a good place to learn a lesson from lawyers—no really. Every lawyer will tell you that they never ask a question of a witness in court when they do not already know the answer. They want no courtroom surprises. Likewise, a project manager should strive to have no surprises at a senior management presentation. Vet everything possible before the big event.

Is the Project on Budget? Budgets can generate the most noise but are often the least critical of the three management questions. Budgets are what senior managers understand the best; after all, they have spent careers crafting them, enforcing them, and learning how to get around them. They can manipulate a budget faster than a politician can change positions. Their adherence to a budget can be fanatical while, at the same time, they can be eminently practical. If the project is needed for the business, e.g., if it will “kill more than it eats” (business speak for “generate more revenue than it costs”), then spending more than anticipated will be approved. Oh, there might be some public castigation of the project manager, but most of that will be for show. If the project is needed, then it will be funded. The project manager just has to utter some public mea culpas, and all will be right.

If the project is considered anywhere between unneeded and frivolous, then the situation is entirely different. An overbudget report is often the catalyst to kill the unwanted or undervalued. This is not an entirely bad situation. Cancelling unneeded projects frees up scarce resources for more valuable work. It can, however, be a blot on the project manager’s career, though some perceptive and resourceful project managers have turned the tables to their advantage by being the one who recommends that, “for the good of the company,” the project should be cancelled.

An awkward budget meeting can point out one important reality of senior management thinking. Both project management tools and project managers themselves tend to focus on actuals (schedule actuals, actual spend, tasks completed), while senior managers are more interested in projections (what will happen when and what will it cost?). Spend more resources and time on when things will happen rather than when things did happen, what costs are ahead rather than what was spent, and what features are being developed rather than what was developed. For example, if you are a nickel overbudget then you need to be prepared to explain the impact it will have on projected costs.

Project Management Review Rule Three: Traditionally, project management reviews focus on the past (work accomplished, milestones achieved, spend so far), but what management really wants to know is the future (when will it finish?, what will it cost?, what am I getting when all is done?). 

Just ensure that focusing on the future is not perceived by senior managers as masking past failures.

Will it Work? This is by far the most important of the three senior management questions but often the least discussed at project review meetings (where the focus tends to be on numerical issued such as schedules and budgets) and the most difficult to answer for two reasons. First, there are so many questions to answer. Functional failure can be caused by a lack of analysis, or programing that does not adequately do what is needed, or the architecture cannot support the production environment (platform, data volume, transaction volume, etc.). The list goes on and on. When reporting on budget and schedule progress, the project manager has many numerical and presumably objective measures; however, there are few mathematical crutches when reporting on feature progress. Progress on the functionality landscape is highly subjective. 

This is where iterative and incremental (I-I) development approaches, such as rapid application development, prototyping, extreme programming, and agile development, etc. come into play. By having user staff intimately involved in the project, providing insight and reviewing work accomplished, senior business management has the input of their own staff regarding the progress and quality of the system so far. There is an added benefit. If user staff assigned to the project are excluded from the preparation and presentation of the project review, then they might take on a more adversarial position, searching for project flaws rather than extolling its virtues. On the other hand, if user staff are charged with reviewing and presenting functional progress at the management meeting, then their inclinations will be more toward supporting the project rather than criticizing it. Many a project manager has suffered a self-inflicted wound by minimizing the role of user project staff. The wise project manager uses business staff assigned to the project as ambassadors to the user community.

Lastly, do not stand up at a senior management meeting and toss a project management hand grenade—giving senior managers bad news cold. Short of announcing at a senior management project review that you won the lottery and are quitting your job immediately, surprises are not a good idea. Moderate less than good news is OK, but senior executives hearing for the first time that the project will not deliver 50 percent of its promised functionality is not. Bad news, particularly about functionality, needs to be pre-sold, ideally with one-on-one meetings with selected senior managers. This is also the time to use your project champion to pour oil on the troubled waters. But do not dawdle. Bad news is like dead fish—it does not get better with age. Too many project managers procrastinate about giving bad news, but as awkward as it is for senior managers to hear about problems from the project manager, it is far worse if they hear about them first from someone else. Any credibility you had will be lost.

Project Management Review Rule Four: Never wait for a formal management meeting to present bad news. Always pre-sell bad news to the project champion or at least one or two senior managers before the meeting. No surprises.

Salty old project managers are awash with tales of presenting terrible news at a senior management meeting and getting no reaction, while getting skewered on something the project managers considered trivial. You never know what will pass without a sigh and what will cause a brouhaha. When in doubt, pre-sell.

Managing the Managers. Like it or not, a project manager needs to manage up as well as down. The project manager techniques that are so successful in managing subordinates are rarely the same techniques needed to manager superiors. Techniques and styles that work so well with programmers might be the absolute wrong thing to apply to user supervisors. The successful project manager has a separate tool kit for each constituency and the number one tool in the manage-up kit is communication (See “Half of Managing is Selling,” SD Times, November 2020). A good project manager uses every opportunity in front of senior staff to sell their project, its benefits, its team, and its project manager. Anything else is shortchanging the project and the user.

The post What do you mean by “communicate?” appeared first on SD Times.

Corporations can be similarly led. Sometimes the power rests within the chain of command. In other organizations, the CEO might rely on an unofficial team of employees of various titles and positions, perhaps not even in the chain of command. It is these insiders who make or influence corporate decisions. 

What does this have to do with IT and project management? Well, put your project planning books aside. The critical decisions about your project might have been made months ago, before you were even assigned to the project, and kept private by a group of people you don’t know, sitting around a table in some unnamed conference room you never heard of, who know little to nothing about IT. 

If you are a project manager, even the best project manager in the world, it is unlikely you will be sitting with that group anytime soon. Even the CIO might be a stranger to that assemblage. 

If your project is building an application to manage IT’s bowling scores, then you can skip this article. Even the project manager of a more corporate relevant though small and not revenue significant project might be able to breeze though the following pages. However, if your project is mission critical, meaning that it plays a major role in the success of your organization, then read on, because, know it or not, your project needs senior representation.

Projects are like wolves, they are useful, but they also have people gunning for them. For whatever reasons, someone, somewhere, will be out to get your project. He might think it’s a waste of money; poorly led, planned, or executed; not needed by the business; or better alternatives are available. Whatever the rationale, he will do all he can to bring your project to a halt. Project naysayers are not evil people, just convinced that a mistake is being made and that they have a responsibility to point it out if not correct it. 

If the naysayer is a junior member of the organization, then there is probably no problem; however, if the project critic is a senior executive, then beware. Somewhere, around some bend or detour you have to take, the critic waits ready to spring on any perceived misstep or error. 

When will the ambush occur? Well, there are a few fairly predictable points.

First Sign of Weakness. Drop the ball, or even bobble it, and you are in trouble. A slipped schedule, budget issues, a vendor not able to deliver what or when resources were promised, or staffing problems are all reasons the viability of the project could be questioned. 

Wrong Place, Wrong Time. When a project kicks off, there is considerable enthusiasm and energy aimed at the undertaking. The project team is charged, users are thinking of how things will be when the systems is in, and managers everywhere are looking to bask in the credit they will take, deserved or not. But enthusiasm will wane. It doesn’t matter that the plan says that the project will not show tangible user results for 8 months, or that the users were told, time and again, that there is a deliverable desert between months one and seven. Sometime, after 3 or 4 months, with nothing end-user oriented to show for all the work besides bills, even the most ardent supporters experience the mid-project blues and start to second-guess their decision. Now add in the naysayers whispering “I told you so” in their ears, and even the strongest supporters start “re-thinking the project.”

There are two ways to avoid the mid-project blues. First, keep the drought short. Try to have some user-focused deliverables that will keep the users happy as soon and as often as possible. Never go more than 6 months before some functionality is installed, and never more than 3 months without some kind of demo. (See “Squandering the Honeymoon Period,” SD Times online, April 13, 2020.)

Second, get a project champion. A project champion is a senior executive, usually from the business side of the organization, who has the respect of peers and the ears of the very top echelons. More specifically, the project champion either sits around that decision-making conference room table or routinely works with those who do. He or she knows what that body is thinking or can influence what they do. Moreover, this senior executive, who truly believes in the system and the benefits it will deliver to the company, is willing to forcefully campaign for the project. 

A good project champion will keep the true believers believing and the naysayers quiet, giving the project team the time it needs/deserves to build the application and deliver the goods. Project champions are worth their weight in gold.

A good project champion can support a project in at least four ways.

Represent the project at the highest corporate levels. As a member of the inner circle, the champion can either advocate for the project (budget, schedules, resources, etc.) at executive decision-making meetings or sometimes make the decisions unilaterally.

Can commit corporate resources. The champion can directly make or, as an executive conduit, influence organizational binding resource decisions. 

Keep the firm focused on the endgame. If the champion is sufficiently senior in the organization, then he or she can cut through corporate red tape, thwart naysayer interference, and clear organizational obstacles.

Clear the decks for the project. The champion is not a member of the project team but rather an important resource to allow the team to do its job. Like a snowplow on a train, the champion clears the way for those who follow behind.

Both Six Sigma (a set of process improvement techniques and rules) and the Project Management Institute (PMI) recognize the role and recommend that projects have a project champion. 

However, even the best project champions need the help of a project manager. A smart project manager will become quite familiar with the project champion and solicit his or her advice in dealing with, and presenting to, senior management. The champion can then float ideas with senior executives, identifying and clearing potential objections and obstacles, before the project team recommends them.

Do Not Confuse a Project Champion with a Mentor

Every project manager should have one or more mentors (official or unofficial) who can help them navigate corporate waters. Mentors provide staff with advice and insight regarding their corporate careers, focusing on individual performance and success. Mentors can help an employee with development and training choices, positioning for promotions, interacting with other staff, and more.

A Mentor Advises a Person; a Champion Advises a Project

Mentor. A mentor is a senior and respected expert in one or more areas of the organization. He or she is knowledgeable, not just in the official procedures and processes of the organization, but also in the culture and unofficial—unwritten—rules of corporate engagement.

There should be no line responsibility between mentor and mentee. Rather the relationship is informal and advisory. The objective is not to have a buddy, but rather someone who can advise the mentee on when he or she is doing something right or when they are on the wrong track. Mentors are not a cheerleading squad—call mom if constant encouragement is needed—they are there to listen to mentee questions and provide factual and practical advice. They are not there to intervene with the mentee’s managers to “fix things.” A good mentor will resist talking to the mentee’s boss, if at all possible, to avoid interfering in the employee-manager relationship or second guessing management decisions.

Everyone in an organization should have a mentor. Some organization’s assign an official mentor; others allow employees to pick their own. Even if there are official mentors, everyone should also have one or more unofficial mentors.

Champion. The project champion is a senior member of the organization who takes a personal interest in the project. He or she regularly attends or is at least a guest at the highest level corporate governance meetings. The champion works closely with the senior executives in the organization (and is often their peer) and can represent and advocate for the project with senior executives. The champion often has the power to influence, if not modify, budgets and project plans, and commit organizational resources. The champion can speak for the organization at project meetings and reviews.

The champion is an excellent audience for the project manager to practice meetings and presentations with senior users and project oversight groups. The champion can recommend strategies and tactics to improve communication and the likelihood of favorable outcomes.

Finding a Project Champion

Finding a project champion can be a challenging task. Luckily, a champion might have existed before the project even kicked off, and have played an instrumental role in its creation. However, some champions decide to take a back seat once the project is underway. This is unfortunate since the champion is often needed more after project kickoff than before. Job one for the project manager is keeping the project champion engaged during the entire project. Explain to a reticent champion the tasks and the challenges facing the project. This needs to be one of the project managers best performances. 

If there was no pre-project champion, then the project manager’s options are limited. With the support of the IT organization, meet with likely candidates and convince them to take on the task. The project manager should learn all he or she can about those high level pre-project meetings. Who spoke up for the project and its budget? Who opposed it? Meet with the candidates and ask for their help. With some luck you might be pleasantly surprised.

Project Champion: A Resource, Not a Friend

Every project manager needs to remember that the project champion represents the organization and the project and not the project manager. For example, a champion might decide that the current project manager is the wrong person to lead the project and needs to be replaced. Both the champion and the project manager need to jointly understand the champion’s goals and responsibilities and the potential consequences of both.

The post Projects, Politics, and Champions appeared first on SD Times.

However, the first fungibility problem, and the core of the fallacy of fungibility, is assuming the fungibility of staff when building, managing, or assessing a team after project kickoff. Applying fungibility to real people is error-prone and can lead to eventual project failure.

Second, Fred Brooks, in his book “The Mythical Man Month,” points out that the larger the team, the more individual effort is required to interact with other team members. Multiple people on a team require resources for dividing up work, coordinating effort, and just ensuring that everything that has to be done is being done consistently. The time required to coordinate work is called communication overhead. Fungibility does not take communication overhead into account. 

RELATED CONTENT: The Fungible Fallacy: Structural impediments to effective project management

The conclusion of part 1 is that while the concept of the staff fungibility might be a necessary evil for project planning, which traditionally takes place before any staff are assigned to a project or before actual team size is known, it should not be used without significant caution after project approval.

Part 2 points out a sociological problem with assuming staff are fungible, discovered by a 19th century French farmer conducting a tug-of-war. 

Part 2: Where None is Better Than Half a Loaf

In the 1890s, Maximillian Ringelmann, a French professor of agricultural engineering, was studying the work accomplished using early farm machinery, and comparing it to the work produced by horses, oxen, and humans. One of his experiments involved a tug-of-war between a man and a scale used to calculate the human’s pulling power. After testing many individuals, he discovered that a single man tugging a rope exerted an average force of 85.3 kg. However, when the same subjects were placed in teams of two, the average force per team member dropped to 93% of when the subject worked alone. When the team size was increased to four, then the force exerted by each team member averaged only 72% of when they worked alone. That number dropped to only 49% for a team of eight. 

Ringelmann found that an individual, who is part of a team, puts out less effort to accomplish a task than when he works alone. Further, the effort of the individual diminishes as the team gets larger. This is known as the Ringelmann effect, later renamed, and more popularly called, social loafing. Unfortunately, it took more than 60 years for anyone to show interest in Ringelmann’s work. Then it launched a firestorm becoming a founding pillar of the new science of social psychology.

Subsequent studies by modern researchers found that social loafing is present whether the task is physical (pulling a rope) or intellectual (such as solving math problems). Researchers also found that the level of social loafing was based on a number of factors, not simply team size. Social loafing, they discovered, was most prevalent when team members feel that:

1. Their individual efforts did not matter. When one is part of a group, they can feel that their contributions to the group are insignificant and that they have little effect on the outcome of the task. These feelings can lead to worker apathy.
2. Assigned tasks are unchallenging. Team members can feel that others on the team are assigned the choice or important tasks, while they were left with the boring or unimportant tasks. Feeling your job is unimportant or that you are not treated fairly in team assignments can lead to social loafing.
3. Little satisfaction performing assigned tasks. Being assigned simple and/or unimportant tasks can rob team members of any personal satisfaction of a job well done or appreciation for their contributions. Karl Marx, it turns out, had it right—performing tasks that do not provide personal satisfaction can lead to the alienation of the worker. Alienated workers simply do not work as hard as those who find personal satisfaction in what they do.
4. A lack of a united team. Social loafing is more prevalent in team members who feel they are more part of a crowd than of a unified team. They feel little need to help the guy next to them or to “win one for the Gipper.”

Social loafing is certainly a problem for any project manager, playing havoc with the notion of staff fungibility—that all staff produce equal work. Unfortunately, this problem has largely gone unnoticed by the IT profession.

One important finding of the research completed since Ringelmann is that social loading is not inevitable. It is possible to mitigate the effects of social loafing through some social psychology techniques.

What’s a project manager to do?

Understanding the causes of social loafing can help the informed project manager reduce its effect by applying a number of remediation techniques.

1. Team size. As mentioned in part 1 of this article, team size is an important contributor to project success—small teams are more productive than large teams. This conclusion is also straight out of Ringelmann and many other researchers. (See “The Big Bang Bust, or Size Does Matter,” SD Times, July 2021)

Small teams give individuals an opportunity to shine. Team member work products are more visible to others and they are often more inline with team goals. Social loafing can be reduced by partitioning big teams into a number of smaller teams, when possible. However, partitioning a team can be a difficult and trying task. Each sub-team needs to provide meaningful and unique work for its staff while minimizing the communications needed across sub-teams.

2. Team spirit. The team should function as a single-minded unit. One of the functions of military basic training is to instill a sense of camaraderie among new recruits—a feeling that they are all in it together. Shared experiences, even negative ones, bond disparate recruits into a unified team that supports and trusts each other. In the business world the same is accomplished with team building exercises.

A crowd is a group of individuals in the same place at the same time. A team is a group of people working together to achieve a common goal. Projects work better with teams than with crowds. Unfortunately, people assigned to a new project might not have previously worked together or even know each other. For all practical purposes they are a crowd. If things go well, over time, the crowd will learn about each other, identify strengths and weaknesses, instill trust, and eventually coalesce into a team. The purpose of team building exercises is to shorten the time it takes to turn a crowd into a team. A good team building exercise can start, if not achieve, that in as little as an afternoon.

Team building exercises can be complex, requiring a large indoor space, considerable props, and overseen by outside behavioral experts; or as simple as an hour or two spent in a conference room with an HR trainer. In both cases, the participants are asked to work with others on small and ideally amusing tasks that demonstrate the benefits of working together. In addition, the hopefully fun nature of the exercise, will generate a sense of camaraderie and familiarity among the participants. Team building exercises have successfully built team esprit de corps or group spirit through simple shared experiences. 

Formal team building exercises work well at the beginning of the project. Mid-project pizza parties, softball games, laser tag, and Friday night “programmer meetings” at a local pub, can contribute to a well-oiled team.

3. Challenging individual tasks. Each team member should be assigned unique challenging tasks. 

One of the project manager’s most important jobs is staffing—assigning team members to project tasks. For many project managers staffing consists of two components: (1) examining the task to be performed and (2) finding someone who can do the job. Sort of plugging work holes with people. But there is more to staffing than that. Project managers also need to (3) be aware of the individual’s personality and work history (too heavy, too many boring tasks, not in the team members skill set, etc.) and assign work based on team member personal dynamics as well as skills. And don’t forget development needs. Some tasks should be dead set in the individual’s strike zone—what they do best. But other tasks should stretch the individual, to learn new skills or expand existing ones.

Every project has boring and workaday tasks that need to be completed. Managers should ensure that these less popular tasks are evenly distributed among team members. No one should be assigned only boring tasks or only the more popular or challenging ones.

4. Measure, evaluate, and communicate each team member’s performance. The performance of every team member should be objectively assessed and feedback provided to the team member. 

In these modern times, project managers are very familiar with HR. There was a time when the personnel department was only involved in hiring and benefits. Now there are a whole range of HR activities that involve the project manager. Have a problem worker? Well HR will require that you document the poor behavior or work. Detailed documentation is necessary before formally chastising or firing a worker. But the good worker? Well HR’s folder on him or her is much smaller. The fact is we spend far more time on the problem child than on the good one. This is a grave disservice to the good worker.

Every team member should know exactly what his or her team leader and project manager thinks of their work. This evaluation should be objective and conveyed to the team member in a timely manner. It is of little use if their only assessment is at the end of the project. The team member should have sufficient time to correct deficiencies and improve performance before the project ends.

5. Recognize individual work. IT loves praising work. We have done our share to keep the tee-shirt, coffee mug, and mousepad industry in business. Every milestone—project kickoff, first system test, starting beta etc.—involves another tchotchke. However, users and IT management praise usually stops at the team level. Individual praise is less common.

No one is suggesting that you praise mediocre performance. This is not summer camp where everyone wins a trophy. However, there is a lot of good work going on between star performers and deadbeats. The yeomen on the team should be recognized for their individual contributions and given a little pat on the back for their achievements. You don’t need to award a tee-shirt, but you should recognize individual contributions. Praise is good but can be overdone. The operative word is more recognition than praise. Individual team members should feel that project management knows who they are, what they do, and their contribution to the project.

Fungibility: The reality of the situation

First, fungibility and its associated concepts of person-month and full time equivalent, are useful when estimating the work required to complete a project. However, their value diminishes significantly once the project starts. Actual team members and actual team size are not fungible. Keeping the fungibility notion alive after project planning can be a costly mistake.

Second, recognizing the causes of the fungible fallacy can help the project manager mitigate them, even if they cannot be eliminated. When to use fungible concepts, attention to team structure and size, and the proper treatment of staff can go a long way to minimizing the fungible fallacy.

The post The Fungible Fallacy: Sociological impediments to effective project management appeared first on SD Times.

Structural Problem One: Our Way Of Counting Staff Can Be Inaccurate And Misleading

Project managers have traditionally had three jobs. The first project manager job is planning the project, including estimating the costs and time needed to complete the work. Planning is needed to sell the project to the users, gain approval, and obtain necessary funding. The second job, once the project is approved, is acquiring the needed staff. This can be a dicey task because needed staff might be committed or assigned to other projects. IT management often plays the major role in deciding who is on what project, with the project manager delegated to a minor role. The third project management job is overseeing the actual work of building the system. 

Project managers have traditionally had three tools for dealing with project estimating and staffing—headcount, person-months, and full-time equivalents (FTEs). Headcount is the actual number of staff on the project at any given time. A person-month is a measure of effort, not time, and is the amount of work one individual can complete in one month. What is nice about person-month is that it is not only countable but you can apply arithmetic operators to it. For example, 10 person-months is half of 20 person-months. A project requiring 100 person-months can be completed in 10 calendar months if the project is staffed with 10 people and completed in 5 calendar months if staffed with 20 people. 

Full-time equivalent (FTE) expresses how many virtual people will be needed to perform the tasks. For example, if an analyst spends 50 percent of his time meeting with users, 30 percent conferring with team members, 20 percent doing administrative tasks such as writing reports and meeting with project management, then the job could be categorized as one-half FTE meeting with users, three-tenth FTE meeting with team members, and one-fifth FTE doing admin. If the project manager wants to have the analyst work 60 percent with users, then she needs to reassign one-tenth FTE to other staff. 

A partial FTE is just what it sounds like, for example a half-FTE is the equivalent of a half-time person, or two quarter-time people or four eighth-time people, etc. In the analyst example, the total work (meeting with users, conferring with team member, and admin) was assigned to one person—one FTE and a headcount of one. However, if staffing is just a math problem, then the job could have just as easily been staffed by a half-time person for the analysis work, a second person at 30 percent working with team members, and two people at 10-percent each working on admin and training. In total, one FTE and a headcount of four. 

Fungibility

Person-months and FTEs work because of a concept called fungibility. Fungible refers to an asset that can be substituted for another asset of the same kind. Fungible objects have no individuation and are interchangeable with all other objects of the same class. For example, U.S. dollars are fungible. If someone owes you 10 dollars then any 10 dollars (one 10-dollar bill, or two 5-dollar bills, or 40 quarters) will do. 

In terms of people, fungibility means that one staff member equals two half-time staff and four quarter-time staff. Fungibility is the mechanism that allows the IT manager and project manager to easily translate FTEs into person-months. 

Taking the Fun Out of Fungibles: The Planning Problem 

Virtually all project planning takes place before the project manager knows who will be staffed on the project and their skills, experience, and salaries. Yet costs and schedules are needed before funding. Most organizations use a standard (cost) model. It might use a generic cost such as all IT staff have a loaded cost of $10,000 per month. Some models are title specific such as: analysts $11,000 per month, designers $10,000 per month, programmers $8,000 per month, project managers $15,000 per month, etc. Standard models, even title-specific ones, assume that all staff in a given category have the same skill level, the same experience, are equally productive, and are paid the same. However, this is never true. Staff skills, experience, productivity, and salaries vary considerably in the typical organization, making standard models problematic. For example, programmer productivity can vary more than ten-fold within the same organization (See “The Most Important Factor in Project Success? Your Staff,” SD Times, June 2020). Therefore, accurate projected numbers cannot be baked into the plan. 

Conclusion One: Real people are not fungible. Costs generated based on the fungibility of staff are, at best, tentative.

But wait, it gets worse.

Structural Problem Two: Team Staffing, Even When Every Team Member Shares The Same Skills And Work Ethic, Might Be Uncountable

You often hear in a movie or read in a novel the refrain, “Put more men on the job.” The phrase is from some confrontation between management and the foreman trying to make the best of a bad situation. The implication is that by adding bodies to the project it will happen faster or at least get done. 

Almost everyone in IT has heard of Fredrick Brooks who, in his monumental book, “The Mythical Man-Month,” confronts the fallacy of just adding bodies to a job to make it finish sooner. Brooks shows that, in fact, added staff can actually further slow down progress. For example, if a 50 person-month project with a staff of 10 is two months behind schedule, adding five more staff might cause it to become three months behind schedule. The math simply doesn’t work. Why? Many reasons. For example, the existing staff have to stop the critical project work they are doing to get the new staff up to speed. Also, numerous studies show that larger teams require more coordination and communication than smaller teams, with the additional time taken away from project work.

Taking the Fun Out of Fungibles: The Communication Overhead Problem

The need for team members to consult with other team members is called communication overhead and is part of the overall project cost in time and effort—even if it is rarely recognized by IT. Brooks and others point out that as staff are added to a project, the communication overhead soars, with some reporting an exponential increase. All of that additional time and effort must to be accounted for, but usually isn’t. The result? You guessed it—the situation goes from bad to worse. 

Assume a team of 21 staff. Using Brooks’ numbers, a team of 21 requires 210 individual staff interactions. If each team member interacts with every other team member once a week for 10 minutes, then 2,100 minutes are consumed each week, or 87.5% of a normal 40-hour workweek. 

Add this wrinkle. Remember FTEs? According to our math the time required to perform some task should be the same whether one person is assigned full-time or four staff are each assigned 25% of the time. The effort should be the same but, owing to communication overhead, it is not. The four people will require more effort and/or more time than a single person doing the job. The problem with FTEs in general, and partial FTE specifically, is that the reality often does not match the math. 

Conclusion Two: Any team larger than one person has to account for communication overhead and the amount of communication overhead depends on headcount, not FTEs, playing further havoc with the fungibility of staff.

What You Can Do About The Project Planning Problem

It is a grave error is to assume that a person is a person is a person—that staff are interchangeable. Person-month/FTE math only works if staff are fungible and, as we have shown, they are not. So why does IT put so much emphasis on FTEs and fungibility? The answer is that IT has little choice because project costs and schedules are often required months before a project starts. Person-month and FTEs are useful, but only at the right time and in the right context. During project proposal or the early stages of project planning, they are often the only means for providing senior management with a ballpark estimate of project costs and schedules. However, they are only useful as a starting point. As soon as actual staff assignments are known, then the project manager should provide more credible numbers. 

It is important that the tentativeness of the project plan, with its FTE-driven budget, be known for what it is—a first-blush look at costs. The project manager, ideally with the help of IT management and the project champion, needs to: (1) explain to the senior user management that the pre-kickoff project plan reflects standard and not real costs and productivity, and (2) review the project plan shortly after kickoff and possibly adjust it to reflect actual project staffing.

Will senior business management go along with this Day 2 project plan review? Maybe not, but even if they do not, at least the project manager has gone on record raising the issue. At the very least, it should help at your court martial.

What You Can Do About The Communication Overhead Problem

Brooks’ model says that a team of 21 people will spend almost 90% of its time comparing notes and little more than 10% doing real project work. There is a partial solution to this problem however—partitioning.

Imagine the 21 person project consists of one project manager and five sub-teams each of four staff, with one sub-team member designated team leader. Each sub-team member communicates with other sub-team members for 10 minutes per week and each team leader interacts with the other team leaders and the project manager for an additional 10 minutes per week. The weekly communication overhead for a partitioned team is 450 minutes per week or 18.8% of a 40-hour workweek. In this example, partitioning the team produced an almost fivefold reduction in communication overhead.

Some project experts are skeptical of Brooks’ formulas. Not every team member needs to individually communicate with every other team member. However, while Brooks’ numbers might overstate the problem, experience has shown that they are directionally correct. Small teams are more efficient than large teams. Turning a single large team into multiple small teams can reduce costs and improve the odds of the project finishing successfully. However, any team with a headcount greater than one must deal with the communication overhead problem, partitioned or not.

Fungibility: The reality of the situation

There are two fungibility problems for the project manager. First, headcount and FTEs play a major role in determining the resources needed to complete a project. However, until the staffing and the structure of the team are known resource requirements are volatile. Once project staffing is finalized, the project manager should review the project plan to determine whether any staffing decisions affect projected project costs or schedules.

Second, team size and team structure play a major role in the resources needed to complete a project. The culprit is communication overhead: the need to keep all team members informed increases significantly as the project headcount increases, potentially playing havoc with costs and schedules. The good news is that communication overhead can be mitigated by partitioning large projects into multiple smaller sub-projects. The bad news is that while communication overhead can be reduced, it cannot be eliminated.

The post The Fungible Fallacy: Structural impediments to effective project management appeared first on SD Times.

If you don’t like the Chaos Report, there are a number of academic studies (hundreds of them) showing perhaps not as dire results but the same message—systems development is a blood sport.

What they all agree on is that there is a fundamental flaw in how we build systems, and the project manager is caught in a real-life Catch-22 situation in trying to solve the problem.

A 2007 study of more than 400 projects in the United States and the United Kingdom titled “The Impact Of Size And Volatility On IT Project Performance, ” is a telling example. The study found that as the project headcount gets larger, the risk of underperformance gets higher. The larger the team size, the greater the risk of failure. A 21 Full Time Equivalent (FTE) project is more than twice as likely to underperform as a 10-FTE project.

OK, you want to reduce project risk, and the plan calls for too many people on the project. What do you do? Well, one option is to spread the project out over time thus requiring fewer staff. Figure 2 (from the same study) presents the level of risk based on the duration of the project. It shows that as the schedule extends out, the risk increases, with 18-month projects encountering twice the failure rate of 12-month projects.

Figure 2 Risk of Underperformance Attributed to Duration

In fact, the project manager can’t do much. As the same study shows, it doesn’t matter whether you thin the staff count and make the project longer or shorten the duration by adding staff, the devil is the project effort (person-months) required.

Thick or thin (many staff or few staff), long or short (long duration versus short duration), a 500 person-month project is twice as likely to underperform as a 25 person-month project. Put simply, Big is Bad.

If big is bad, go small. Now, that should be the end of this article, but making big projects small is not so easy. Below are a few suggestions for accomplishing the small is beautiful effect.

Out of one, many

The simplest way to reduce the risk of one big project is to make it multiple small projects. Slicing up the megaproject into bite-sized pieces is the best way of bringing in a large project. The result should be a number of subprojects, or phases, each with their own staff, project manager, goals, and deliverables. But exactly how big should the subprojects be?

From the study’s findings, one could conclude that a good team size would be in the range of 5 to 15 staff and a good duration somewhere in the 3- to 12-month range. Other authors have different but not terribly dissimilar numbers. Reviewing more than a dozen research studies, one would not be wrong in considering the average recommended team size seems to be in the four to seven range with a duration somewhere between three  and nine months. For simplicity, we refer to the four to seven staff and 3- to 9-month duration as the project sweet spot. 

The project sweet spot has a number of advantages. Its small headcount minimizes the required communication overhead, while the short duration mitigates the honeymoon problem.

RELATED ARTICLE: Squandering the Honeymoon Period

The project sweet spot can be implemented serially or in parallel, or in any combination. A serial implementation has the mini-projects or phases executed one at a time, one after the other. If mega-project X is broken down serially into mini-projects A, B, and C, IT could theoretically use the same staff on each project. When A is complete, the team moves on to B, etc.

Parallel execution requires multiple project teams working on the different mini-projects at the same time. Parallel projects require different team members for each project—sharing staff across projects defeats the purpose of phasing. 

Most phasing is serial because it is often the easiest way to divide a project, however, parallel phasing becomes more desirable when there are significant schedule pressures.

There are a number of technical challenges to successful project phasing.

Communication. One of the reasons to break up a large project into smaller pieces is the communications overhead problem—as the number of team members increases, the time and effort needed to keep everyone up to speed on project activity increases exponentially. However, communication between teams is now needed, particularly if the phasing is parallel. While most intra-team communication is verbal, multi-team communication is often in writing, further increasing communication costs. 

Partitioning. Exactly how to carve up the megaproject into multiple smaller pieces called mini-projects, subprojects, or phases is not always obvious. To do it right, the project manager (or whoever is tasked with parsing the project) needs a good understanding of the finished system and the tasks to build it. 

Figure 2 shows a sample application data flow diagram (DFD). Processes or functions are depicted with rounded rectangles (example: A2, C1, etc.). Data stores or files (static data) are represented by open rectangles. Arrows depict the flow of data (data in motion) to and from data stores and communication (data sharing) between processes. 

Figure 2: Megaproject Divided into Three Subprojects (A, B, and C)

Selecting which processes to include in a mini-project is critical to development success. A phase or subproject should consist of processes where the communication (data sharing) between them is the highest. Phase boundaries should be defined to minimize cross-phase communication. 

In Figure 2, processes A1, A2, A3, and A4 have the most significant communication between them and are kept together as a subproject, while a similar decision is made about processes B1, B2, and B3.

Budget. Partitioning a large project into bite-sized chunks can have a negative impact on effort and schedules. Communication overhead was discussed above, but in addition, multi-phased projects often require more analysis time (as business users are interviewed and re-interviewed) and testing time as the various sub-systems are integrated. Project managers for the various mini-projects need to incorporate the additional required effort and time into their individual plans.

Testing. The testing of the individual subprojects is usually neither harder nor easier then testing a similar portion of a mega-project, however, it can be different. If the mega-project is divided serially into phases, then testing other than in the first phase might require revisiting previous phases. For example, imagine a mega-project divided into subprojects A, B, and C. If the subprojects are executed serially, then testing subproject C might uncover changes needed to earlier completed subproject A. This problem is not limited to serially executed subprojects, but can also occur in parallel subproject development and even in a big bang approach where the work on the various portions of the system is completed at different times. However, it can be more prevalent and acute in serially developed subprojects.

Integration. A megaproject that is divided into components can require some effort to reintegrate once the mini-projects are complete. Not necessarily a difficult task, but one that needs to be taken into account.

Throwaway Code. Project phasing often requires additional non-application code that is not in the final production system. This code is required for the proper testing and integration of phase components that will eventually need to interact with components in other, not yet developed, phases .

RELATED ARTICLE: Don’t Throw Away That Throwaway Code

Slicing up what the user sees as a single project can present some management challenges.

User management. Senior business managers are often suspicious of any “project” that does not deliver the entire end result. They see a potential “bait and switch” where A, B, C was promised but they are only going to get A or A, B. Further, the additional time and dollars required for the phased system adds insult to injury. To top it off, they are skeptical of the argument that partitioning will eventually cost less (no write-offs for cancelled projects, or increased maintenance costs for underperforming systems) while increasing the odds of getting what they want.

IT management. Some IT organizations face a significant systems development backlog with needed applications having to wait months or even years before project work can begin. Some senior IT managers pressure current project managers to move ahead as quickly as possible to free up resources that can be applied elsewhere. 

In spite of the cons, and because of the pros, phasing a large systems development project into manageable sub-projects is the single best planning action a project manager can take to increase the odds of project success, and, in spite of the increased development costs and schedules, one of the cheapest.

This article is adapted from George Tillmann’s book Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at georgetillmann@gmx.com.

The post In project management, size does matter appeared first on SD Times.

Let’s face it, no one would do that. A rational person would first figure out what the house should look like, the number of rooms it needs to contain, how the rooms are connected, etc. When the plans for the house are complete, then the correct amount of supplies can be delivered, the tools taken out, and construction begun. Architects work with paper and pen to plan the house, then, and only then, carpenters work with tools and lumber to build it. Everyone associated with home building knows that you figure out what is wanted before determining how to build it.   

RELATED CONTENT:
The most uninteresting reason your project might fail
5 tasks project managers must perform to ‘sell’ their proposals

Arguably, the fundamental principle of systems development (FPSD) is also to figure out what the system is supposed to do before determining how to do it. What does the user want? What does the system have to do? What should system output look like? When the what is understood, then the how can start. How will the system do it? How should the system generate needed output? The how is the way users get what they want.

The IT industry has long recognized that confusing the what with the how is a major cause of project failure resulting in user dissatisfaction from poor or absent functionality, cost overruns, and/or missed schedules. Ensuring that the what is completely understood before attempting the how is so important that it was engraved into the dominant system development life cycle methodology (SDLC) of the time—the waterfall approach. 

For those of you who just recently moved out of your cave, the waterfall SDLC consists of a series of sequential phases. Each phase is only executed once, at the completion of the previous phase. A simple waterfall approach might consist of five phases: analysis, design, coding, testing, and installation. 

In this approach, the analysis phase is completed before the design phase starts. The same is true for the other phases as well.

The good news is that with the waterfall approach, systems developers did not have to remember to put the what before the how because their SDLC took care of it for them.

Then iterative and/or incremental (I-I) development came along and, the rest, as they say, got a little dicey.

Although there are dozens of I-I approaches, they are all variations of the same theme: make systems development a series of small iterative steps, each of which focuses on a small portion of the overall what and an equally small portion of the how. In each step, create just a small incremental part of the system to see how well it works. Vendors like to depict I-I development as a spiral rather than a waterfall, showing the iterative and incremental nature of these approaches.

Using an I-I approach such as prototyping, a session might consist of a developer sitting down with a user at a computer. The user tells the developer what is needed, and the developer codes a simple solution on the spot. The user can then react to the prototype, expanding and correcting it where necessary, until it is acceptable. 

This is obviously a very different way to develop systems than the waterfall approach. What might not be so obvious is that the various I-I methodologies and techniques, such as rapid application development, prototyping, continuous improvement, joint application development, Agile development, and so on, still involve figuring out what is wanted before determining how to do it. 

Rather than looking at I-I as a picturesque spiral, an I-I approach can be viewed as a string (or vector for you programming buffs) of waterfall phases where each cycle consists of a sequence of mini-analysis, mini-design, etc. phases. However, rather than each phase taking six months they could be no longer than six weeks, or six days, or six hours.

It might take a half-dozen cycles of sitting down with a user to figure out the requirements (the what) and then coding the results (the how) before showing them to the user for additional information or changes, but the principle is always the same—understand the what before determining the how.

However, too many developers throw out the baby with the bathwater. In rejecting the waterfall approach, they mistakenly ignore the basic what before the how—the FPSD. The result is the reappearance of that pre-waterfall problem of project failure resulting in user dissatisfaction from poor or absent functionality, cost overruns, and/or missed schedules.

Why? How could something so well understood as ‘put the what before how’ be so ignored? Here are three common reasons for this troublesome behavior.

Reason 1. Impatience (Excited to Get Started)—Many in IT (the author included) started their careers as programmers. Programming is a common entry-level position in many system development organizations. It is understandable that new (and not so new) project team members are anxious to start coding right away. In their haste, FPSD is not so much ignored as short-changed—corners cut, important (sometimes annoying) users not interviewed, schedules compressed, etc. The result is an incomplete understanding of exactly what the users want.

Reason 2. Not Understanding the Value of Analysis—Analysis, or whatever your call it (requirements, logical design, system definition, etc.) is the process of learning from users their requirements (the what) and then documenting that information as input to system design (the how). However, analysis has endured some heavy criticism over the past few decades. Some feel that it is overly laborious, time consuming, error prone, or just not needed at all. The result can be an incomplete understanding of what the new system needs to do.

Reason 3. Confusion about the FPSD and the Waterfall Approach—The waterfall SDLC is viewed by many as a relic of IT’s past, offering little for today’s developers (not entirely true, the waterfall approach still has its uses, but that is a subject for another time). Unfortunately, the what-how distinction is closely tied to this approach so any rejection of the waterfall approach contributes to skepticism regarding any what-how talk.

What’s a project manager to do? How do you ensure the what is understood before the how is undertaken? There are three things the project manager can do.

Training—The problem with most systems development rules and guidelines is that the reason they should be followed is not always obvious. Or has been forgotten. Systems developers tend to be an independent and skeptical bunch. If it was easy to get them do to something, then documentation would be robust and project managers would earn half what they do now because their hardest job would have disappeared. No, managing a team of developers is like teaching an ethics class in Congress—difficult, underappreciated, and often exhausting. The one saving grace is that systems developers like to create great systems. The vast majority of developers take great pride in doing a good job. The project manager needs to tap in to that enthusiasm. 

The easiest way to get systems developers to do something (other than forbidding them from doing it) is to convince them that doing it is in their and the project’s interest and that separating the what from the how is in that category.

But wait. You can hear the challenge right now. “We are using Agile development, so we don’t need to separate the what from the how.”

The answer is that the purpose of the what-how distinction is not to create separate development phases but is to make developers think before they act—to ensure that before the design hits the page or a line of code is entered on a screen, the problem is mulled over in those high-priced heads.

Is this approach counter to Agile development or any iterative-incremental approach? No. Read the books and vendor manuals more closely. There is not one author or vendor who believes you can skip the thinking if you use their tool or technique. The problem is that many of them are not sufficiently vocal about the value of thinking before acting.

Discipline—The problem is usually not knowing (most know to complete the what before starting the how), the problem is doing. A good way to get team members to do the right thing is to codify the desired behavior before the project kicks off. Rules, standards, and strong suggestions presented before a project starts are more likely to be accepted and followed by team members than mid-project changes, which can be seen as criticisms of team member behavior.

The project manager needs to lay out the project rules of engagement, including such things as the SDLC method or approach to follow, the techniques and tools to use, documentation to produce, etc., all focused on ensuring the what is completely understood before starting the how. 

Then comes the hardest part of the entire project—enforcement. The project manager needs to ensure that the rules of engagement are followed. Failure to enforce project rules can undercut the project manager’s credibility and authority. A few public executions early in the project do wonders for maintaining that project manager mystique.

Collaboration—Want to influence a systems developer? Need to convince developers to follow systems development best practices? Then have him or her collaboratively meet with other systems developers. The team walk-through is a great vehicle for this.

In a team walk-through the developer presents, demonstrates, and defends his or her work, not to users, but to other team members. The developer walks the other team member through the user requests, his or her analysis of those requests, their solution to the request, and finally any demonstrable work products. This friendly IT environment is a useful way to test if the developer’s work is thorough, efficient, and complete.  

This is should be a slam-dunk. Team walk-throughs can be very motivational, inspiring (shaming) underperforming developers into producing better results while providing overachievers an opportunity to show off. In both cases, the user, the project, and the project manager win.

George Tillmann is a retired programmer, analyst, systems and programming manager, and CIO. This article is adapted from his book Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at georgetillmann@gmx.com.

The post Confusing the What with the How appeared first on SD Times.

NASA investigators determined that a definitional problem doomed the craft. The engine burn was timed to slow the craft down and place it in a safe orbit 68 miles above the surface of the planet. However, the instructions for the burn were wrong, resulting in the craft attempting to orbit Mars at a disastrous altitude of only 35 miles. The problem: The NASA’s spacecraft was programmed to use the metric system while the commercial contractor sent burn information to NASA using the English system (pound-seconds instead of Newton-seconds). The burn lasted too long; the probe attempted too low an orbit, and burned up in the Mars atmosphere.

This is a pretty dramatic case of the definitional problem. The engineers’ thinking was sound, their math was accurate, their numbers were correct, just the definition of those numbers (English versus metric) was misunderstood. 

A contentious area, fueled by definitional problems, is downtime. Imagine a situation where every Sunday at 2:00 a.m., IT takes email offline for preventive maintenance. At 2:10 a.m., the VP of marketing tries to send an email to the head of Europe only to get a message that email is not available. Later that month, the VP of marketing is surprised to see an IT report saying that there was no email downtime for that month. Result: The VP resolves never to trust IT reports again. 

Who is right? Was email down that month? Depends on what you mean by down. IT believes that down means an unscheduled interruption in service, while the user believes that down means the service is unavailable, regardless of cause. Both groups have well-formulated, complete, and appropriate definitions, both definitions are adequate, accurate, and acceptable. They just don’t agree.

Of more consequence is user management being told by IT that the total cost of their new accounting system will be $1,000,000, only to find that IT did not include in its budget transition, end-user documentation, or training costs. Question: who is correct? Answer: both.

When multiple parties are right, or at least not wrong, then the basis of the disagreement is probably definitional. In the example above, IT believes that the development cost consists of the hardware, software, and staffing expenses to analyze, design, code, and test a system, but not implementation, user documentation, and user training charges, which are to be borne by the user organization. The user believes that the check he wrote for developing the system was the entire cost of getting his new application up and running, and is unaware of any additional “hidden” costs.

The problem
Arguably, half of all IT-user disputes are definitionally based or exacerbated.

The definitional problem appears in multiple forms.

Problem 1: Multiple conflicting well-defined definitions — One word or concept can have multiple legitimate and accepted but inconsistent definitions. Each party is using a formal definition that is well defined, correct, and broadly accepted by users in the field, just different. 

The NASA case is a good example of this. Both the NASA team and the external contractor used complete, accurate, and accepted definitions of thrust. Each used its definition correctly and arrived at a situationally correct answer. Each team was aware that there were two distinct legitimate definitions. Unfortunately, each team assumed that the other team was using the same definition it was. 

Problem 2: Multiple but not all well-defined definitions — One word or concept can have multiple definitions, with at least one a legitimate, detailed, and correct definition and at least one an inexact, although popular, definition.

This is a huge category that can be very frustrating for professionals. It usually involves a very technical and exact definition that is used by professionals in a field and the same word having a similar but much less exact definition used by non-professionals.

Take the word, theory. For a scientist a theory is a proposition that has been tested, probably multiple times, and has been proven to be sufficiently correct to predict future events. In empirical science, there is no higher state of truth. The popular definition of theory is quite different. Non-scientists use the word theory to mean unproven and, at best, a guess.

The ambiguous use of theory has led to some interesting if fruitless discussions. Anti-evolutionists point out that evolution is only a theory and therefore not proven science. Scientists say that the fact that it’s a scientific theory says that it is proven.

Problem 3: Non-specific, fuzzy, or incomplete definitions — While there are words that do not have a specific and well accepted definition, it is often the case that some people know, or think they know, what they mean.

Many projects define effort in person-hours, person-months, or person-years; where person-year is the work one person routinely completes in one calendar year. Person-months are everywhere in IT and throughout many non-IT project-focused organizations as well. It is not an overly technical term and probably 95 percent of the people you meet on the street will tell you they know what it means. It is undoubtedly one of the most ubiquitous project-related terms. But what does it mean? Exactly how much work gets done in a person-year? Experience shows that the IT year can vary from fewer than 1,500 work hours to more than 2,000 hours. Why the difference? Many organizations remove activities such as vacation, training, and administrative time from the person-year. Other organizations believe that these activities are the cost of doing business and should be included in the definition. Some take a stand in the middle counting certain activities in the person-year, such as administrative time, but precluding others, such as vacations. Yet, anecdotal evidence indicates that fewer than one IT organization in four has an exact definition of effort, formally publishes the definition, communicates it to relevant parties, and ensures that whenever it is used it is used correctly. 

This problem can appear in IT where two project teams, or an IT organization and an external contractor, have different and poorly communicated definitions for common systems development words. 

Problem 4: Obfuscation — Sometimes words are used to hide rather than elucidate meanings. Just bought a 2019 Ford Focus? That’s a used car, while the 2016 BMW across the street is a pre-owned vehicle. 

Interested in decision support systems (DSS)? Well that’s old hat. Years ago the DSS gave way to executive information systems (EIS). The difference? Well, if there is any, then at least 90 percent of it is marketing hype. The EIS? Well it was replaced with online analytical processing (OLAP). The difference? You guessed it. OLAP? Well it was replaced by, er, was it business intelligence (BI) or predictive modeling (PM)? Whatever! Were all of these the same? No, there were differences and improvements. Did all deserve a different name? No. General Motors might change the design of the Corvette every year, but they still call it a Corvette. 

What you can do
This is one of the few IT areas where the solution is relatively simple, easy to implement, and painless to use.

Solution 1: Define, define, define —It might take a little upfront effort, but all technical and even business terms should be formally defined and placed in a project glossary. Do it once and it can be used again and again. The project glossary should be part of the contract between the user and IT—even vendors and IT. It can also be an appendix to reports, a chapter in development documents, or referenced as a stand-alone text. 

Definitionally challenged? Find a source (book, vendor documents, websites, etc.) that you can live with in toto or as input to your own project glossary.

Solution 2: Define first, then develop —The project glossary should exist before any development is started, planning completed, or costs discussed. This is important for two reasons.

First, it is easier to gain agreement on terms before anyone has a vested interest in the definition. Agreement on who will pay for end-user training before any contracts are signed is a lot easier than the argument that can occur after budget finalization. Down the road surprises are almost never good.

Second, a number of mid- or post-project disagreements can be settled easily by referring to published and agreed-upon definitions. The same is true within the project team. Defining documentation or testing can abrogate many potential project squabbles as team leaders maneuver to meet deadlines.

Solution 3: Agreement on operational definitions is required; agreement on conceptual definitions is not — A conceptual definition is an intangible, theoretical, and abstract concept that you hold to be true. You might believe that man never landed on the moon, that climate change is a hoax, or that existence is not a predicate. That is your right. 

An operational definition, also called a working definition, is an agreement to use a precise definition in a specific context. The context for an operational definition can be temporary (before the year 2000 or starting next year, etc.) or limited to a specific project, department, location, company, or even country. Operational definitions make it easier for everyone on a team to work together. For example, you might strongly disagree with the team’s definition of temporary storage, but, for the purposes of communication and team harmony, you agree to use it during the project.

Solution 4: Keep the definitions updated—Technology changes rapidly and vendor marketing terms even more so. The project glossary should be revisited at the beginning of each project to see whether any definitions need to be modified, new terms introduced, or old terms removed. 

Unless you are a lexicographer, you probably do not find the subject of terminology that interesting and certainly not as a part of project management. It does have a sort of bowtie image. However, a great many of the problems a project manager will encounter involve IT and sometimes even business terminology. It is important that developers and users understand what is being said, even if they do not necessarily agree with the definitions used. 

George Tillmann is a retired programmer, analyst, systems and programming manager. This article is excerpted from his book Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at georgetillmann@gmx.com. 

The post The most uninteresting reason your project might fail appeared first on SD Times.

Now imagine your best systems programmer in the same job. You might have the one programmer who would do well, but many coders would have difficulty selling ice in the desert. What’s worse, they would probably be miserable doing it. The fact is most IT people have neither great selling skills nor the inclination to acquire them. 

That’s not the bad news. Here is the bad news. All managers—business, IT, and project—if they are to be successful—are salespeople. If you are a project manager, then one of your jobs is to sell your project. The initial proposal meeting—it’s a selling situation. The kickoff meeting—it’s a selling situation. The progress review—it’s a selling situation. 

So, what’s a reserved project manager to do? The successful salesperson needs to know a lot about his/her client, which, it turns out, is the first of five tasks the project manager/salesperson needs to perform.

ONE: UNDERSTAND THE CLIENT. To successfully sell the project, managers need to know their client and what that client is likely to buy.

Identify the Clients and Stakeholders. For the average project, IT’s clients are certainly business user management and IT management, although clients, sometimes called stakeholders, can also include others such as employees (for a payroll system), the government (tax systems), and external customers (customer service). 

Who Are the Project Stakeholders? There is an old tale about the pet supply company that introduced a new premium dog food. Despite its upscale image, sales were miserable, so the company hired a topnotch marketing consultant to help them. The company executives explained to the consultant that they conducted an extensive advertising campaign, ran nationwide store promotions, and even went as far as to gain celebrity endorsements, but the dog food still did not sell. The consultant then asked a single question, “But do the dogs like it?” The stunned executives looked at one another for anyone who had an answer. None did.

Not all stakeholders have a seat at the management table (for example, customer service reps), but they may have proxies (such as an employee union) whose interests need to be represented and understood.

Understand Client and Stakeholder Goals. Why is the user willing to spend good money on this project? Does the project need to be completed before a certain date (Christmas selling period or next tax year, for example)? There are issues that might not be publicly known but that the project manager needs to know.

Know What Clients and Stakeholders Expect From Project Management. What do users and IT management expect from the project and the project manager? You would think this would be obvious, but you will be surprised to learn that user management, even IT management, can harbor diverse expectations. Even though they all want a functional system, on time, and on budget, they might not all share the same priorities. User management might be more concerned with cost and least concerned with schedules, while IT management, mindful of its project backlog, is more concerned with schedules. Understanding clients’ priorities can be complicated and tricky, but it is essential for a successful project.

TWO: PRE-SELL ALL MAJOR IDEAS. In a fair world, the project manager would be showered with accolades for successes and flogged for failures. Unfortunately, sometimes the clients get it backward. The complexity of the project plan, arcane technology, and bizarre terminology can lead even the most fair-minded business executive to the wrong conclusion. Whether a project manager is to be praised or eviscerated at a review is not always obvious ahead of time. Sometimes a small incident or misunderstood progress is enough to land a project manager in hot water. 

Pre-selling is having one or more informal one-on-one meetings with critical executives to discuss the meeting’s topics before the formal review session. The purpose is threefold. First, the project manager wants to inform senior management of the issues to be discussed, ensure that they are understood, and correct any misconceptions before the formal meeting.

Second, the pre-selling meeting can be used to gauge senior management’s reaction to the meeting issues. This gives the project manager a heads-up on whether executives are likely to be amiable, displeased, or even hostile to issues that are scheduled to be raised at the meeting. The project manager can then prepare a presentation targeted to the expected response.

A third advantage of pre-selling is the opportunity for the project manager to correct or mitigate issues upsetting to user management before the review meeting. Sometimes a quick fix can change a career-limiting situation into advancement. 

THREE: BE PREPARED. It is amazing how many project managers go into senior review meetings unprepared.

Formal Presentations. The formal project review is the primary venue for selling the project. Many project managers go into a meeting thinking that the presentation is the slides and that they only provide background and commentary. They have it backward. The primary means of communication is the presenter speaking. The slides only provide background information and underscore some of what is said. The successful presentation is not defined by a series of charts and graphs, but rather by the story the presenter tells. The story includes what has been completed, what remains to be done, and any issues or implications going forward. It should be an informative sales pitch— not fluff, not feathers—but hard facts that are relevant to the audience. The best stories include a message that everyone present takes away with them.

Informal Meetings. Every project manager should meet informally with every important stakeholder. For some stakeholders, one or two meetings during the entire project are sufficient. Others might want the project manager to meet more frequently. Each stakeholder has his or her own interests and concerns and might even be disinterested in other project issues to the point of rudeness (talk bits and bauds to the CFO, and the meeting might turn hostile).

Many project managers have less success with informal stakeholder meetings than with formal ones. The reason: lack of structure. Most formal meetings follow a formula: reserve a conference room, provide coffee and donuts, present a few PowerPoint slides, ask for questions, muddle through some answers, take the remaining donuts back for the support staff.

Informal meetings can be a minefield of misunderstood protocols, subtexts, and missed opportunities. However, following a few simple rules can help you to avoid being thrown out of executive row.

Prepare to take the lead. A business unit president once complained that the project manager for an important project showed up at her office and apparently thought they were going to chat. The project manager was told not to come back until he had something specific and relevant to talk about. 

The solution is to never show up empty handed. One project manager always prepared three PowerPoint pages of project issues that he kept in his briefcase. If the stakeholder had some project issues she wanted to discuss, then the pages never left the briefcase. If the stakeholder had no project issues on her mind, then the project manager brought out the three pages. 

Follow the top three/bottom three rule. Projects are often large, and the interests of stakeholders can be arcane. It is easy for a project manager to get stuck with little to say on an important topic. You cannot prepare for everything, you cannot know everything, but you can cheat—well not cheat but rather improve your odds of not looking like an idiot.

Formal meetings tend to focus on facts: accomplishments to date, budget status, issues going forward. Informal meetings tend to be more question and concern focused, with the client or stakeholder asking questions, sometimes at the prodding of the project manager. Questions might be about why the project manager is comfortable with progress or whether he or she needs more resources. Many executives want to ensure that their staff, the business experts associated with the project, are providing what the team needs.

Being prepared for the un-preparable is possible if the project manager limits the subject to the top three/bottom three facts about the three questions management wants to know most about a project. 

Question 1. Is the project on schedule? Will the project end when is it supposed to end? The project manager should know or have in her briefcase the top three things that need to happen for the project to finish on time and the bottom three (most probable) reasons it might not. 

Question 2. Is the project on budget? Will the project cost what it was projected to cost? The manager should have information on the top three examples of strict budget management as well as the (bottom three) cases of (real or potential) budget overrun.

Question 3. Will it work? Will the system do what it was promised to do—features and quality? The project manager should be able to show or discuss three examples of functional success (top three) but also three cases (bottom three) of (real or potential) functional concerns.

Why should the project manager have examples of project failures in her briefcase ready to share with stakeholders? First, the client might already know. It is a common management technique to ask questions of a subordinate when the superior already knows the answers to test the honesty of the subordinate—a powerful barometer of credibility and trust.

Second, it is better to get the bad news out in the open in a one-on-one meeting, where emotions can flair with minimal consequence, rather than in a more public venue. Both stakeholder and project manager have a more private setting to work out differences and resolve problems.

Why limit examples to the top three and bottom three? Would not the top five or bottom ten be better? The truth is the average project manager’s mind can only hold so much. Knowing three facts shows that the project manager has some mastery of the subject. Knowing six would add little to the meeting while doubling the project manager’s preparation work. And let’s face it; absorbing more than three of anything is beyond the span of attention of many senior executives.

FOUR: USE THE PROJECT CHAMPION OR YOUR MENTOR. A project champion is a senior executive who feels some ownership of a project. The champion might hold an official position with name and job description in the project plan or charter or could be serving based on an informal arrangement solidified behind closed doors. The champion often has the power to influence, if not modify, budgets and project plans and commit organizational resources. The project champion can function both as a project-friendly customer for the project manager and as an excellent salesperson for the project.

Every project manager should have one or more mentors (official or unofficial) who can help him or her navigate senior executive waters. While senior executive mentors might be uninformed on the latest systems development techniques, they are probably pros on selling ideas to business managers and corporate executives.

Use both the champion and the mentor to ensure your message to management is targeted (at what you want to achieve by the meeting), concise, cordial, and frank (the truth). Hone your message by running your presentation past them in a safe and supportive environment.

FIVE: MANAGE EXPECTATIONS. This fifth task—manage expectations—is the most important of the five and the one that comes the closest to encapsulating the other four. 

An expectation is an anticipation or mental image of something that will happen sometime in the future. In systems development, users have an expectation of what the application they are paying for will do when installed. Of the three project planning variables (cost, time, and functionality), the one that most commonly involves expectation problems is functionality or features. The user believes that the system will do X, but instead it does Y. When systems development expectations get out of whack, it is usually not the person with the strange expectations who suffers the consequences, but IT. 

Expectations commonly go awry for one of two reasons: 

The user is unsure or unaware of the details. Confusion often exists about what the system will actually do (its functionality) when complete. 

Expectations stray over time and can grow between their first inception and their reality. Like the guy who buys a Ford Focus, but by delivery time expects a BMW, there are senior executives who want to limit costs and development time during the project funding cycle but, forget their frugality by project end. They are amazed to find that features, discarded as too costly during planning, are missing from the final system.

What’s so insidious about expectation disease is that users are absolutely positive they are right. They firmly believe they told IT exactly what they wanted, and IT, owing to its tradition of underserving or its devious nature, has purposely ignored their requests and sabotaged the system. 

If you have not experienced this response, then you might find it hard to believe, but it is a real problem. Ask around. You will find someone in your organization who has experienced this horror show first hand.

There is a solution to this problem that is also the poster child for this article—manage expectations. Managing expectations means providing near continual, honest, and unvarnished feedback to the user. Three simple rules apply.

First, be clear about what the system will do. (1) During project planning, create a small summary document (one page would be ideal) specifying what the system WILL and, more important, what it WILL NOT do. Make sure the user signs off on this document. (2) Keep this document in your briefcase and bring it to ALL meetings with a user, but only use it if you have to.

Second, focus on the progress IT has made in building the system. (1) Make sure that progress reviews are user friendly and geared to the three issues that concern users (cost, time, and functionality). (2) Be honest—you’re probably not a good enough liar to snow senior executives.

Third, state exactly what IT and users need to do to successfully complete the project. (1) Lay out exactly what you will be doing between now and the next user meeting and any issues you think may arise. (2) If you need anything from the user (staff, cooperation, funds, etc.), this is the time to ask for it.

The takeaways for being a great project manager are simple:

1. Recognize that all managers—business, IT, and project—if they are to be successful, are salespeople.
2. The project manager needs to know who his or her clients are and what they expect from the project team.
3. The key to selling success is constant, honest, and informative communication with the user and managing their expectations. Without constant feedback, expectations can go awry.

George Tillmann is a retired programmer, analyst, systems and programming manager. This article is excerpted from his book ‘Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes‘ (Stockbridge Press, 2019).

The post 5 tasks project managers must perform to ‘sell’ their proposals appeared first on SD Times.

Farfetched? Of course it is. No one would ever put a new surgical team together with new technology and new operating room procedures with a real patient. It is a scenario for disaster. A new systems development project? Well, it’s done all the time, isn’t it!

IT is abuzz. Senior business management just approved the development of a new expanded order management system. They approved a budget to purchase a new No-SQL database, 70 new workstations, a half-dozen servers, and hire seven new programmers and analysts.  This will give IT the opportunity to try that DevOps approach it has heard so much about.

See any parallel? 

New IT technology is expensive. Just purchasing one database management system can set an organization back six figures even before the required new hardware and staff training. Many IT organizations cannot afford to purchase such items out of their operating budgets. Big-ticket items have to wait for the big systems development projects with their business management funded big budgets. New, high profile projects, with funding from project sponsors, can be a time of renewal for IT. That’s the good news. The bad news is that all those new items increase the risk of project failure. 

Go back to the surgery example. Being operated on by a famous surgeon is good. Having the latest operating technology is also a plus. Keeping hospital procedures up to date is a sign that the organization is trying to do better. Throwing them all together for the first time—not a good idea. Yet, that is exactly what IT does. Given two projects, one a 3-month, 9 person-month, internal to IT inventory system, and the other an 18-month, 200 person-month, business critical order processing system; which gets the tried and true tools and techniques, and which gets the high-risk, brand new tools, and techniques? It’s insane.

Ideally, you want your best-trained staff, using tried and true tools and techniques, on the most important projects, and you want to train staff and try, test, and learn how to use new tools and techniques on small, ideally internal-to-IT projects. How do you do that given that IT can only afford to purchase the new tools and techniques when undertaking a new business-sponsored project? The accompanying diagram frames the conundrum.

The four categories in the diagram just might hold the answer to IT’s problem. 

Category 1: Missed Opportunity

Unless IT has great staff sitting around doing nothing, wasting the best people, experienced in the use of IT’s methods, techniques, and tools, on non-business critical applications is a waste of resources. The risk is bored staff and senior management wondering if systems development is overstaffed.

Category 2: Best Foot Forward

This category is IT’s raison d’être—its reason for being. Being able to staff a high-profile business critical application with IT’s best and brightest using technology they are familiar with is the ideal. It’s the lowest risk with the highest reward.

Category 3: Learning Experience

This is IT boot camp. It is the ideal place to train inexperienced staff as well as try out new methods, tools, and techniques. The challenge is finding the funding to bankroll the low priority work. This is a good test of IT’s ability to sell systems development investment to business management. There is also a silver lining for IT. While IT is working to automate the business, it is often one of the least automated departments in the business. Certainly a case of the shoemaker’s kids. Because of either priorities or budgets, IT is one of the most labor-intensive departments in many organizations with numerous opportunities for automation. 

However, getting approval for Category 3 projects can be a challenge. Some strong IT management, a well prepared business case, and a good project champion should grease the skids for IT to identify, approve, and fund Category 3 projects, even if they are not kicked-off right away. Why not start them right away? Because the smart IT manager will always have a number of Category 3 projects waiting in the wings for just the right time (see below) to launch them.

Category 4: Suicide Alley

Run! The risk of failure is very high. This death march is often predetermined by the inability of IT to sell to business management the need to invest in new staff and/or technology before committing the farm.

Why are there Category 4 projects? The answer is because that is how funding works. IT wants a new database management system and four servers to support it and senior business management says, what for? Why can’t you use what you have? However, if senior business management wants that exciting new business product and IT says, yes, we can do it, but we will need a new… You get the idea. 

What Can Systems Development Do?

There are no great answers, but a few not-so-great-ones can provide some help. It’s unfortunate, but Category 4 projects will not simply vanish on their own.  However, there are a few things IT can do. The remedy is risk shifting, turning that risky Category 4 project into two projects, a Category 3 followed by a Category 2. The idea is to shift the risk from the Category 4 project to a Category 3 project. Below are three options in order of preference.

Option A. Schedule a non-business critical project just before the business critical one.

Because many non-business critical projects are short and business critical projects long, it might be possible to schedule a non-business critical project, containing the new staff, tools, or techniques, before the business critical project kicks off. A 6- to 8-week low-priority project might just provide the training and tool familiarity staff need to get up to speed for that business critical project, thus turning that Category 4 disaster into a Category 3/Category 2 win. This is why the smart IT manager always has a Category 3 project waiting for the right moment.

Option B. Run a non-business critical project simultaneously with the business critical project.

Sometimes the business critical project needs to start immediately. IT might have to start the non-business critical project in parallel with the business critical project. Not ideal and the non-business critical project will probably negatively impact business critical project schedules, but it is unavoidable. The more disparity between the non-business critical and business critical schedules (the longer the business critical project schedule) the better. This option is not as good as Option A but it might have to do.

Option C. Bundle the Category 4 project with a non-business critical Category 3 project, doing the non-business critical work first.

If running a non-business critical project before, or in parallel with, a business critical project is not possible, then the best IT can do is to find a non-business critical project related to the business critical project, and bundle the two projects together making a new single project. Then the non-business critical tasks could be tackled first, using the new staff and new technology, allowing a de-facto training period before the business-critical tasks are started. The challenge is finding the right non-critical project that, from a user perspective, fits in well with the critical project, can be built before the critical project work, and the business is willing to fund. 

The project manager is faced with many technical and personnel project issues but perhaps the most important success factor is risk management, in this case shifting risk from business critical applications to non-business critical applications.  It is hard to find a single action that can benefit the business, IT, the project team, and the project manager. This just might be one of them.

George Tillmann is a retired programmer, analyst, systems and programming manager. This article is excerpted from his book ‘Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes‘ (Stockbridge Press, 2019).

The post New tools are great… just not for critical projects appeared first on SD Times.