This is why the job of the project manager should revolve, almost exclusively, around enabling developers to do just that. However, it can sometimes be difficult to keep developers happy and building while also staying on top of progress and pushing the project forward.

How the project manager role has changed

According to Sílvia Rocha, VP of engineering at OutSystems, the skills that make project managers successful have undergone a transformation in the last two decades.

“I think before, when our projects were very much waterfall, the role of a project manager was a little more on the forefront of the governance,” Rocha said. “And now with the flourishing of agile practices, I think project managers have moved a little bit to the side.” 

She explained that with this shift towards more agile practices, projects often have multiple leaders, such as Scrum masters and product owners. Because of this, project managers have had to reinvent themselves quite a bit.

Rocha also cited a heightened level of autonomy at the team level as a reason why the role of the project manager is changing.

“I think a lot of rethinking and redesigning of what that role is and the interactions that the project manager has is something that I have definitely seen the industry do,” she said.

One of the ways that the role has been altered is the added emphasis placed on empathy and interpersonal communication skills.

Yishai Beeri, CTO at the developer workflow automation company LinearB, said interpersonal communication skills are key when it comes to building trust with developers.

He explained that having effective interpersonal communication skills leads to a more positive and open team culture, enabling team members to feel comfortable enough to come to the project manager if something is not going as expected. 

“If you can trust the developers to tell you when things are not progressing as required or when things are starting to accumulate risk, then you can focus solely on these things and assume that everything else is going as planned,” Beeri said. 

Building this trust also allows project managers to not automatically feel worried when team members are not constantly offering up status updates. When everyone trusts each other to make issues known, then silence becomes a positive thing. 

Rocha went on to explain that in the choice between a project manager with higher level technical skills and one with superior interpersonal skills, the latter would most likely provide better outcomes.

“Putting things in a simple and outcome-focused way and letting the team know that you are there to assist and that you are there to remove dependencies and roadblocks for them lets them know that you feel their pain, that you realize what it is like to be in their shoes, and that you are actively working towards helping them,” she said. 

Additionally, Beeri explained that avoiding the blame game is essential when it comes to communicating and building trust with a team.

He emphasized that project managers should always care more about solving the issue than pointing a finger at any developer who may have had a hand in causing it. 

“And I think a lot of this takes time and it comes from having worked together for some time and learning to understand each other’s cues or way of communicating,” Beeri said. “It can be hard to replicate that without the experience of working as a team and working together to understand how different people communicate about the same things.”

How project managers can be a benefit to developers 

In an SD Times-led discussion on the “Dev Interrupted” Discord server, Conor Bronsdon, co-host of the Dev Interrupted podcast, explained that project managers can either be a benefit to the team, or a massive hindrance.

“Ideally, they’ll enable engineers to focus on deep work, particularly coding,” Bronsdon said. “However, it’s very easy for project management to turn into a blocker if the system is constructed in a way that breaks up focus time and creates switching costs.”

He went on to say that project managers should be intentional when it comes to creating the right system for the developers on their team, and they should be sure that the developers understand why the system is important.

“If you don’t create a system that works for your team, and ensure they have the context they need about why the project manager system is important, you’re going to create problems,” Bronsdon explained. 

In that Discord discussion, Beeri added that a common mistake project managers make is always chasing the current status on every item. 

He expanded on this, explaining that if the project manager is constantly asking for status updates or time estimates while developers are untangling and working through complicated problems, it can end up slowing progress in the long run. 

“A great project manager has enough dev chops to get a feel for progress without constantly asking, know how to use tools to augment their take on reality, and have the patience to manage the project with the uncertainties inherent to dev work,” Beeri said. “They also proactively manage up to shield devs from the execs/stakeholders that are also standing in line to ask ‘when will it be done?’ five times a day.” 

Bronsdon explained that it can be easy for a project manager to become frustrated if it seems like developers are dragging their feet on providing the manager with information or updates that are vital to their role. 

Understanding that the challenges developers face are different from the manager’s own helps to create a path to reach a resolution that leaves everyone feeling heard and validated. 

“This requires excellent communication skills and the ability to tailor that communication to your different audiences,” Bronsdon said. 

Prioritizing the developer

When trying to foster open communication and understanding, it is important to also be mindful of the developers’ time. 

Yishai Beeri, CTO of the developer workflow automation company LinearB, explained that oftentimes project managers fall into the trap of overloading their team with meetings in an attempt to facilitate communication. He warned that this is an almost-instant productivity killer.

“[Constant meetings] also give the project manager a feeling (some would say illusion) of control,” Beeri said. “Like ‘I know what’s happening and I know where we’re going,’ but great project managers are comfortable with uncertainty.”

He went on to say that a good project manager is one that centers their communication around risk areas and blockers as well as pushing context to the developers instead of pulling status updates from them. 

According to Beeri, good project managers utilize asynchronous communication options wherever possible and only utilize synchronous avenues to tackle real problems. 

This works to allow developers to be more in charge of their own time, fostering heightened productivity as well as a better relationship between team members and the manager.

He also stressed the importance of managing dependencies as a project manager. He warned not to fall back on old and anti-Agile habits such as trying to map out the dependencies and timeline in advance.  

Rather, Beeri advised project managers to focus on gaining “local” visibility to current and near-term dependencies.

“[A good project manager should] suggest minor shifts in order of execution to resolve them, as well as focused over-communication to mitigate their impact,” he explained. “They also develop a nose for common dependencies/blockers down the line and proactively suggest steps to avoid them.”  – Katie Dee

Accommodating a remote setting 

Rocha also discussed how the transition to remote work has altered the role of the project manager. She said with less face-to-face opportunities, project managers have had to find new ways to tap into the working processes of their teams. 

She said that in the beginning, project managers struggled with this and often tried to overcompensate for the distance and inject themselves too much into the work developers are doing, leading them to become overbearing with their teams.

Beeri also touched on this, saying that since going remote, offering developers high-level empathy has become a bigger challenge than ever. 

He explained that because so much of a human being’s capacity for communication and empathy relies on non-verbal cues, the mediums of communicating in a remote working world have become a hurdle for project managers to overcome.

“Some of these non-verbal cues get lost in screen-based communication… And in some cases this also makes scheduling hard when you do have to synchronize people together,” Beeri said. “Getting everyone in the room together is obviously easier when we’re all in the same office, so those parts have become more difficult.” 

Rocha went on to say that bringing in games and tools that add fun to arduous, but necessary, meetings and tasks has been useful. “I have seen the most successful project managers find their place in this new reality in techniques where they almost gamify a number of the processes that are core to a good and functioning team,” Rocha explained.

Rocha also emphasized the importance of approaching conversations with team members from the perspective of adding value for the end user.

She explained that this is a method that project managers should use in order to avoid falling into a helicopter style of managing because it contextualizes conversations and updates around something that is important to the developer, rather than it being a box on a checklist. 

With this, Rocha stressed that the project manager should constantly be positioning themself as a helper rather than as merely a process guide.

“Especially building a new product from the ground up… a lot of the work that is happening for these products is very overarching and one of the things that will make you a rockstar project manager is if you are actually helping in the alignment across the many teams in a way that developers see as valuable,” she said. “Then they see that dependencies are better catered to, they can go faster, they are more productive, they are not stuck waiting on other teams.”

According to Rocha, this is the best way to be seen as an asset to the team rather than a blocker. The project manager should exist as an enabler that works to heighten the productivity of their developers. 

The post Soft skills become imperative to be an effective project manager 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.

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.

“As your organization starts to grow, you’re trying to accomplish so much more. So how do you do that? It’s not just by adding more Agile teams across the business. It’s also not just about speed or delivery velocity. We’ve learned along the way that it’s about creating a shared vision across the business and building the right things,” said Brook Appelbaum, director of Product Marketing at portfolio management and work management company Planview.

Organizations who have seen success at the team level often make the mistake of adding more Agile project teams to solve problemsw. Sure, they end up with a bunch of fast-moving teams, but those teams are operating in silos, without the necessary coordination and connection. “They are not really realizing the true benefits of Agile,” Appelbaum explained.

 To be successful at scale, organizations have to take the learnings of their Agile teams and apply them at scale: incorporating feedback loops, iterating and coordinating work across a much more complex structure – and key to all of this is a shared vision. By connecting teams and enabling them to see how their work fits into the bigger picture, Appelbaum believes organizations can improve their ability to plan, coordinate, improve their time to market, and gain a host of other Agile benefits.

“As you start to grow, some of the building blocks of Agile – transparency, collaboration, continuous improvement — become so much more important because you have to be really thoughtful about how you engage, explain, coordinate, share, and iterate to create value at every turn,” she said.

Calculating your Agile ROI

In an effort to help organizations better understand their Agile efforts at scale, Planview recently released the Agile Transformation ROI Calculator. The calculator aims to shine a light on Agile’s art of the possible. It is designed as a way to facilitate hard conversations around Agile transformation successes and failures, and provides organizations with a way to look at cost optimization, reducing time to market, and improving employee job satisfaction and productivity.

 “Often when an Agile Transformation isn’t going as expected, it’s due to reasons that are harder to measure: cultural mismatches, ‘performative’ Agile or lack of executive commitment,” said Appelbaum. “The ROI calculator provides critical information that shines a light on some of these challenges, and provides real metrics that can help organizations carve a path forward to success.” 

The ROI calculator highlights metrics that include how long it takes to get a major initiative or epic to completion, and if those times can be improved. It sheds light on whether teams are working in isolation or if they’re able to communicate, coordinate, plan and work together as a cross-functional group of teams. 

Additionally, it estimates job satisfaction and reduced employee turnover for Agile team members that are able to utilize their favorite Agile team tools. For example, different teams like to work with different tools, Planview provides integration capabilities so teams can still work within their existing processes or tools of choice without disrupting their workflow or productivity. As a result, organizations can get that consolidated view of what’s going on across the business, while keeping their key developer talent happy.

However, Appelbaum also noted that, “Organizations must begin to identify and address some of the challenges that are preventing them from realizing true success with Agile at scale, whether cultural, procedural, or even technical: for example, are the products you’re using limiting your ability to scale? It’s paramount to figure out how to connect [teams], how to get them to plan together, synchronize and collaborate together because that’s really what it’s all about, being able to take these big, important, complex initiatives and decompose them into bite-size chunks of incremental value delivery.”

Planview plans to bolster the calculator in the future. “One of the things we hesitate to talk about is Agile risk and failure, but it does happen…there is still a level of failure in every type of project and we are looking to add some metrics around those mis-steps as well,” said Appelbaum.

The calculator was designed as a way of facilitating a conversation within the organization about their current and future Agile successes. If you’d like to learn more about Planview’s Agile ROI calculator or Planview’s Agile solutions visit their website.

Content provided by SD Times and Planview

The post Maximizing the ROI of your Agile transformations appeared first on SD Times.

The technical integration of the company’s offerings “will offer dev teams detailed project visibility and team-based metrics by correlating data across projects, code, Git activity and releases,” the companies said in their announcement of the partnership.

In a December interview with SD Times, Dan Lines, COO at LinearB, explained that project management historically had a top-down mindset that gave metrics to executives, but didn’t help developers. The LinearB solution, Lines told SD Times, “can see where a pull request stalled and send a Slack message to get someone to review it,” among other developer-focused features. He went on to explain that the features in LinearB are tied into ceremonies such as a daily standup and retrospectives. With LinearB, development teams don’t have to give status updates at the standups; that information is automatically provided in the tool’s dashboard. Instead, those teams can talk about the problems they’re having advancing the project toward its goals. “Commits, branches, and pull requests all have visibility” with LinearB, he said Meanwhile, Clubhouse also emphasizes developers in its collaborative project management solution, which aims to overtake Atlassian’s Jira by providing a project management tool that “complements and enhances [developers’] existing workflows,” the company said in the partnership announcement. 

In a March 2019 interview with SD Times, Clubhouse founder Kurt Schradere  said, “I think we’ll see a movement away from structured, monthly road maps to sort of a continuous flow of information, your big things, and we want to enable that so organizations can move quickly, have their work in there but be able to pull back so everyone that needs to participate can get the next feature, the next value out the door, and still work together in sync.”

In today’s partnership announcement, LinearB co-founder and CEO Ori Keren said, “Coupling LinearB Software Delivery Intelligence with Clubhouse team-focused project management provides data-driven insights to gauge project progress in real time and better focus team resources on the work that matters most.”

Among capabilities the integration will provide is a pulse timeline view that the announcement said gives “detailed visibility of every feature, bug and chore by showing a live feed of activity from branches, PRs and releases for Clubhouse stories.” Further, it said the integration will enable real-time improvement of active projects by highlighting blockers, delays, high-risk code and branches merged without review for Clubhouse stories.

A shadow work detector helps with more accurate resource allocation by finding developer work in Git that’s not attached to a Clubhouse story; and an advanced cycle time dashboard adds bottleneck detection by visualizing the time across individual development phases such as coding time, PR pick-up time, PR review time and release time, the announcement stated.

The post LinearB, Clubhouse partner to provide software delivery intelligence appeared first on SD Times.

“Our founders worked on large engineering teams and were frustrated using the popular project management tools that exist today, they created Clubhouse to offer a more enjoyable experience and better alternative for developers,” according to the company’s website. 

More information is available here. 

C3 unveils the C3 AI Ex Machina
The newly announced C3 AI Ex Machina is designed to “reinvent no code AI,” according to the company. It is a next-generation predictive analytics solution that enables users to developm scale, and produce AI-based insights without any coding knowledge. It features prebuilt connectors to data sources, a drag-and-drop interface supported by AutoML; and pay as you go cloud resources. 

“C3 AI Ex Machina enables anyone to combine their business expertise with no-code AI to deliver predictive insights that their company can take informed action against,” said Ed Abbo, C3 AI president and CTO. “C3 Ex Machina offers a tried, tested, and proven path to rapid enterprise AI application development and deployment. It empowers anyone with subject matter expertise to significantly improve their organization’s ability to make timely and contextual data-driven decisions.”

GitLab changes its subscription model
The company is moving to a three-tier product subscription model and phasing out its Bronze/Starter tier. Current Bronzer/Starter users will have a year to transition to its new model. 

According to the company, it has quickly evolved over the last couple of years that the Bronzer/Starter tier is limiting it from improving the solution for everyone. GitLab believes phasing out the tier will help it improve usability, availability, performance, and security and compliance. 

“Over the last few years, GitLab has evolved into a complete DevOps platform. Many Bronze/Starter customers adopted GitLab just for source code management (SCM) or continuous integration (CI), but GitLab is now a robust DevOps platform that can replace entire toolchains. GitLab customers are achieving faster releases, lower toolchain costs, and more productive developers,” Sid Sijbrandij, co-founder and CEO of GitLab, wrote in a post. 

Tiers will now include Free, Premium and Ultimate. 

Esri announces ArcGIS platform
The new geospatial platform as a service solution aims to help developers integrate location capabilities into apps, business systems and products. It includes direct access to location services through APIs and web frameworks. 

“With the release of ArcGIS Platform, developers now have access to professional-grade content and capabilities they can readily plug into their apps, allowing them to stay on budget while delivering enormous value by reducing time to market,” said David Cardella, Esri product manager for developer technologies.

The post SD Times news digest: Project management provider Clubhouse raises $25 million, C3 AI Ex Machina, and GitLab’s new subscription model appeared first on SD Times.

“Software project management is broken,” Lines told SD Times in a recent interview. “Developers don’t want to have ‘Big Brother’ looking over their shoulder.”

LinearB has created a new tool to help development teams overcome challenges with extant project management tools that are “good for planning but don’t add value once dev teams start building,” the company said in a statement about today’s product rollout.

In its announcement, LinearB said its solution provides developers with actionable information where they work — in Git and Slack. The solution, Lines told SD Times, “can see where a pull request stalled and send a Slack message to get someone to review it,” among other developer-focused features. He went on to explain that the features in LinearB are tied into ceremonies such as a daily standup and retrospectives. With LinearB, development teams don’t have to give status updates at the standups; that information is automatically provided in the tool’s dashboard. Instead, those teams can talk about the problems they’re having advancing the project toward its goals. “Commits, branches, and pull requests all have visibility” with LinearB, he said.

This improved visibility helps organizations gain clarity into what to work on, when to add staff and where to invest in automation, the company said in its announcement.

And, with the coronavirus pandemic accelerating the work-from-home culture that is growing, LinearB supports asynchronous development by giving everyone real-time visibility into projects, so they don’t need to wait for status meetings or manual updates to advance their work.

LinearB also hosts a Discord community to give project leaders a home to exchange issues they face or gain tips from their peers, Lines said. Right now, there are about 350 development leaders in the community.

The post Startup takes data-driven approach to software delivery 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.

Throwaway code refers to the temporary software programs and routines created to help in the coding, testing, conversion, and implementation of the final (deliverable) system. There is almost universal use of throwaway code in creating conversion software, the programs used to move data from the old filing system to the new one.

After the conversion is successfully completed, the conversion software is often discarded, leading to the label, throwaway.

Although conversion software might be the most obvious use of throwaway code, there are many other examples. Programmers use throwaway code in unit testing to display application variables at different locations in the program. Database teams create one or more databases, long before the final database design is complete, to give application programmers access to the data they need to do their job. Throwaway code can also be used to link together programs to simulate an integrated system.

Some developers create entire test systems, occasionally rivaling the deliverable system in size. These test systems house test data in temporary test databases, run the test data against the system to be tested, analyze and report on test results, and then refresh/reset the entire test system so that the test can run again.

Near the end of the development cycle, a series of throwaway subsystems prepares the computer environment for the new system. Besides the conversion programs, there are back-out systems that, if the conversion from old system to new does not go well, remove the new system, replace it with the old one, and apply to the old system any data activity (adds, modifies, and deletes) generated by the faulty new system.

How much throwaway code is written for the average systems development project? Accurate numbers are hard to come by, but anecdotal information would indicate that in a few situations half of all code written during development is throwaway, with 20-25 percent a viable average.

How important is throwaway code to systems development? Well consider that almost every commercially available development tool—from code generators, debuggers, and testing tools, to GUI generators, cross-reference tools, directories, and more—started out as someone’s throwaway code. At some point, some smart entrepreneur thought there was an opportunity to share the best throwaway tools with the systems development community…for a price.

However, there are two problems with the current approach to throwaway software. They are:

• Too Tactical or Ad Hoc

Throwaway code, with the possible exception of a conversion subsystem, is often considered the domain of the programmer. Individual programmers decide how much throwaway code they will create, when they will create it, and what it will look like. When they are done with it, if it is useful, they might keep it in a private library or folder; if it is only mediocre or worse, they might delete it.

• Too Often Unplanned

Project managers work hard to ensure that all deliverables are considered when creating the project plan. The project manager needs to know exactly what will be delivered to the user to calculate costs and schedules with some hope of accuracy. This is a daunting task. Figuring out what has to be delivered, before what has to be delivered is defined, is difficult enough, but this is only the start of the project manager’s headaches. Because throwaway code can be considerable in size, perhaps 25 percent of the total code written, it needs to be accounted for when developing the project plan.

Sometimes the project manager is astute enough to include conversion software in the plan. Rarely are any other forms of throwaway code, such as back-out subsystems, included. The truth is that throwaway code is usually a planning afterthought.

There are two solutions to these problems that are, in fact, great opportunities to improve planning while reducing costs and enhancing productivity.

First, make throwaway code an integral part of the project and project management
The project manager should consider the need, development, and use of all throwaway code as both an integral part of the system being developed and its potential for reuse.

A famous French politician once said that war was too important to be left to the generals. Ignoring any potential wisdom that might be in that statement, it can be said with confidence that throwaway code is too important to be left to the programmers. Its status needs to be raised from coding tool to potentially important subsystems requiring project manager, analyst, and designer attention.

Management can delegate unit testing to programmers, but major issues, such as conversion, system testing, and back-out systems need to be given management attention.

Entrepreneurial wisdom should be applied to IT to propagate best practices. Routines that were deemed throwaway should be examined for their potential future use. Reuse can be as simple as storing no longer needed code “as is” or generalizing routines for a more varied and general adoption. This approach is not new to software vendors, who view their internal software libraries of reusable code as a critical systems development advantage that provides a foundation for better and cheaper products.

Any IT shop can do the same for little or no cost. It just requires the project manager, or someone delegated to the task, to visit the trenches in search of throwaway gems. Then project managers or IT needs to see that worthy routines are properly documented, housed, and their use encouraged.

Second, include throwaway code in the planning process
Recognize that throwaway code can be a considerable part of the overall systems development project and that its full impact is often underestimated. Ensure that throwaway code costs and schedules are bundled it into the plan, even if it is only exists as an overhead item.

Study the impact of throwaway code on past projects for more accurate estimates. Involve other project managers—be it with a quick coffee break or a formal meeting—to uncover organizational experiences with throwaway code and institutionalize the results.

Make sure that, going forward, throwaway code is an integral part of all post-project reviews. Document the actual impact of throwaway code on the project, not just what was planned.

This is an opportunity for the project manager to shine while improving systems development performance at little or no additional cost. Deals like this are hard to come by. The wise project manager takes advantage when they do.

This article is excerpted from Tillmann’s book ‘Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes‘ (Stockbridge Press, 2019).

The post <span class="sdt-premium">premium</span> Don’t throw away that throwaway code appeared first on SD Times.