Project estimation offers transparency regarding resource prerequisites, allowing managers to assess the viability of initiating and concluding a project within predetermined schedules. 

This pivotal process involves the meticulous prediction of essential factors, including resource allocation, project duration, and associated costs. In this article, we delve into the core concept of software project estimation, emphasizing its importance in the technology sector and its fundamental role in software development.

At its core, software project estimation is both an art and a science. It serves as an indispensable tool for project managers, developers, and stakeholders, guiding them through the intricate process of software development. By leveraging estimation, teams can navigate a clearer path to project completion, efficiently manage workflows, and set well-defined expectations.

The Significance of Software Development Estimation

First and foremost, software development estimation provides a roadmap to predictability, as it offers a clear, well-defined path for the development team and stakeholders. This clarity is not merely advantageous; it is essential for informed decision-making, realistic expectations, and prudent resource allocation.

Software development estimates serve as guardians of risk management. In an industry rife with inherent uncertainties, these estimates function as early warning systems, identifying potential pitfalls and enabling proactive risk mitigation. When surprises are minimized, and contingency plans are in place, project teams can navigate the challenges of software development with confidence.

Furthermore, the application of software development estimates is vital for budgetary purposes. By providing a comprehensive view of expected costs, these estimates assist organizations in allocating financial resources effectively, preventing budget overruns and financial strain.

The Superiority of the Agile Approach in Estimation

The Agile approach has emerged as a beacon of innovation and adaptability in the realm of software development. It shines brightly in the context of software project estimation, and for good reason. Agile’s intrinsic flexibility and iterative nature make it exceptionally well-suited for accurate and dynamic project estimation. 

This approach acknowledges the fluidity of software development. Unlike traditional Waterfall methodologies, which aim to plan every aspect of a project up front, Agile embraces change. It divides projects into manageable iterations, allowing for ongoing adjustments and refinements as requirements evolve. This adaptability is invaluable when making accurate estimates in an environment where change is constant.

The Agile life cycle places a strong emphasis on collaboration and transparency. This approach fosters a shared understanding of project objectives, priorities, and potential challenges among team members and stakeholders. This shared understanding leads to more accurate estimation, drawing upon the collective knowledge and expertise of the team to ensure that estimates are grounded in real-world insights.

Lastly, Agile estimation often employs relative estimation techniques such as story points or planning poker. Instead of attempting to estimate absolute timeframes, these techniques focus on comparing the complexity and effort required for different tasks relative to one another. This relative estimation method tends to be more accurate and less time-consuming than attempting to estimate in absolute terms, which can be challenging in the dynamic world of software development.

The 7 Key Steps of Software Project Estimation: An In-Depth Overview

Let’s delve into the fundamental steps of software project estimation.

Step 1. Define the Project Scope

The journey of software project estimation commences with a comprehensive understanding of the project’s scope. This involves defining project objectives, identifying the target audience, and specifying the features and functionalities to be included. A clear and well-documented project scope serves as the basis for all subsequent estimation efforts.

Step 2. Gather Detailed Requirements

Once the project scope is established, you’ll have to gather comprehensive requirements. This entails engaging with stakeholders, end-users, and subject matter experts to compile an exhaustive list of specifications. Thoroughness in this phase is essential, as missing or misunderstood requirements can lead to significant discrepancies in the final estimate.

Step 3. Task Breakdown

With a solid understanding of the project’s scope and requirements, it is imperative to break down the project into manageable tasks or work packages. This granular approach allows for a more accurate assessment of the effort required for each component of the project. Common techniques for task breakdown include Work Breakdown Structures (WBS) and User Story Mapping.

Step 4. Estimate Effort and Duration

Estimating the effort required for each task is a critical step in software project estimation. This estimation often involves assigning numerical values, such as hours or story points, to tasks. Teams can employ various estimation techniques, such as expert judgment, historical data analysis, or parametric estimation models, to arrive at these values. Additionally, estimating the duration of each task or work package is essential to create a realistic project timeline.

Step 5. Account for Risks and Uncertainties

No software project is devoid of risks and uncertainties. Therefore, it is crucial to identify potential risks and uncertainties that may impact the project’s progress and adjust the estimates accordingly. This step involves risk analysis, contingency planning, and factoring in additional time or resources to mitigate unforeseen challenges.

Step 6. Validate and Review Estimates

Software project estimation is not a one-time task but an iterative process. It is essential to validate and review the estimates with key stakeholders, including the development team, project managers, and clients. Feedback and insights from these stakeholders can help refine the estimates and ensure that they align with project objectives.

Step 7. Document and Communicate Estimates

The final step in the software project estimation process involves documenting and communicating the estimates clearly and transparently. A well-documented estimation report should include details about the assumptions made, the methodology employed, and any risks or uncertainties identified. Effective communication with all project stakeholders ensures alignment and fosters realistic expectations.

The post Mastering Project Estimation: A Complete Guide appeared first on SD Times.

Zenhub Enterprise 4.0 offers various productivity-enhancing integrations and a new platform experience, eliminating the requirement for users to possess a GitHub account to utilize Zenhub.

“While the cloud has taken the enterprise by storm, many of our largest customers still run a hybrid model with mission-critical data kept on-premise. Zenhub Enterprise 4.0 is designed specifically to support this requirement,” said Aaron Upright, Zenhub’s co-founder. “We’re excited to bring all of the innovation that we’ve recently launched in our cloud product to our on-prem customers. In particular, we think our new platform capabilities will address a growing need we see in larger organizations to consolidate technical and non-technical teams into the same project management solutions.”

With Zenhub Enterprise 4.0, organizations are now visible at the time of onboarding to users signing up with the same email domain as the Zenhub Organization creator. This eliminates the need for new users to receive an invite in order to join their organization. 

Also, the Allowed Domains feature enables organizations to specify the domains from which they accept requests, providing an extra layer of security and speeding up user onboarding, the company explained. 

In this update, every project on the roadmap gets a dedicated flyover that describes the project and highlights its contributors. Additionally, Zenhub now offers Zenhub Issues, a feature that allows teams to collaborate within Zenhub without a GitHub account. Zenhub says this feature is intended to be an alternative to GitHub Issues and is ideal for tracking non-development tasks. Users can convert Zenhub Issues into GitHub Issues, providing a way for individuals who don’t use GitHub to initiate tasks that may eventually become development-related.

The post Zenhub Enterprise 4.0 introduces new integrations for on-prem teams appeared first on SD Times.

According to Zenhub, this new offering focuses on the team rather than the individual and can help with managing projects and tasks, categorizing and prioritizing work, and other productivity-related activities. 

Zenhub Labels suggests labels for information when data is added to the system, saving developers time and improving accuracy. This feature is available in public beta starting today, while all of the following features will be added soon.

One of the upcoming features is AI Estimations, which predicts how challenging a task will be for a team and what resources are needed.

AI Prioritization suggests priority levels for new tasks based on past behavior, ensuring that high-priority work is placed at the top of the backlog. 

Zenhub AI also includes a Daily Feed that can be useful for stand-ups because it provides insights into what has been completed and what still needs to be done, both that day and in the near-term future. The company plans to add sentiment analysis to this feature so that it can surface issues that team members might be stuck on or struggling with..

To help teams better review their work, Zenhub AI can generate summaries of all the work done by the team during a particular sprint. This feature integrates with Loom so that teams can share demos of the work they’ve accomplished.

And finally, AI Retros can provide insight into how teams can improve in the next sprint by surfacing what went well and what issues they faced.

“Zenhub is currently leading the market in integrating AI to help developer teams become more  productive,” said Tyler Gaffney, CEO of Zenhub. “Our approach to building AI is different from most vendors today as we are building in ‘public’ with complete transparency. Our objective is to thoughtfully  build AI for real-life use cases by actively collaborating with our end users and customers. Hence, we’ve  also announced our early access group, where participants work with the product team directly in shaping  how Zenhub AI works. This is just the beginning of the journey, but we’re excited about the potential to  positively impact the day-to-day activities of software teams.” 

The post Zenhub’s project management tool now gets help from AI appeared first on SD Times.

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.