DEV Community: Pro Project Managment

Presale Managers: Increasing Margins and Driving IT Companies Toward Success

Pro Project Managment — Sun, 04 May 2025 00:44:05 +0000

In project management, each stage of the project lifecycle plays an important role. One of the most critical but often underestimated stages, in my opinion, is presale. This is the phase when the company interacts with the client, gathers requirements, proposes solutions, and lays the groundwork for project initiation.

Many IT companies try to save costs by relying on regular sales managers during the presale stage or do not recognize the need for a dedicated employee for this role. This approach is not ideal, especially when the project requires precision, detailed planning, and deep technical expertise. Here, we will thoroughly examine what presale is, what a Pre-Sale Manager does, and why it is better for successful project implementation to have a dedicated Pre-Sale Manager rather than entrusting this task to a standard sales manager.

What is Presale?

Presale occurs before the project begins and involves activities related to preparing and collecting all project details, as well as accurately defining goals, requirements, risks, timelines, and costs. It is during this stage that full interaction between the client and your company takes place, where key project parameters are validated.

The main goal of presale is to create a well-thought-out proposal that is most beneficial for both the client and the development company. This stage involves decisions on technology stack, resources, deadlines, and financial terms. In IT projects, this phase is especially crucial because even a small mistake at the start can lead to significant problems later on.

Key tasks of a Pre-Sale Manager include:

Clarifying all requirements with the client (identifying the client's needs);
Presenting your company to the client (introducing the company, its services, and advantages);
Assisting in lead qualification (for example, a technical specialist better understands whether the client's needs can be met using the company's capabilities);
Preparing and presenting RFPs (Request for Proposal). Fully managing the proposal preparation process and ensuring deadlines are met. Missed deadlines at any stage, from presales onward, are common issues. Meeting deadlines enhances the company's reputation and fosters a positive image with the client;
Participating in Q&A sessions with the client to identify needs, answer questions, and facilitate the process. The presale manager ensures a balance so that the client does not feel overwhelmed by minor questions and remains actively engaged;
Creating harmony among the client, IT, marketing, and sales teams for sustainable and effective relationships.

Where is a Pre-Sale Manager Effective?

Let's look at a typical sales process:

Lead generation — identifying prospective clients and establishing contact; all lead generation activities happen here.
Familiarization with the product/domain — gaining a deeper understanding of the client's business and daily operations to better meet their needs.
Contact with key leads — organizing responses and developing relationships.
Opportunity assessment — exploring and verifying potential for future collaboration.
Client presentation — presenting innovative solutions to identified problems and a strategic roadmap for partnership development.
Deal closing — final negotiations and signing contracts, including advance payments.
Follow-ups — maintaining contact and developing relationships with existing clients.

From these stages, the presale manager is particularly useful in:

Familiarization with the product/domain. The Pre-Sale Manager will know the domain and understand the client much better than a salesperson. This knowledge helps salespeople better understand what is going on in their clients' minds.
Opportunity assessment. With a deeper understanding of the domain and technologies, the Pre-Sale Manager can see all possibilities for collaboration.
Client presentation. The Pre-Sale Manager can speak the client's language, understand their pain points, and identify how to achieve maximum effectiveness during presentations.
Deal closing. It is often necessary to adjust agreements on the fly to best meet the client's needs. The Pre-Sale Manager knows which parts of the proposal can be tweaked without negatively impacting the company’s future.

In conclusion, the maximum benefit from a Pre-Sale Manager is typically seen when dealing with large, complex requests, such as those arising from RFPs (Request for Proposal). It looks something like this:

Visualization of Pre-Sale Manager actions during large RFP requests.

When do conflicts arise during presale?

Presale is always a stressful situation because all participants find themselves in a new, often unfamiliar context. Under tight deadlines, it is necessary to quickly get acquainted with the client, understand their problem, evaluate possible solutions promptly, and prepare a proposal that satisfies both the company and the client.

Main conflicts during presale often occur due to a lack of understanding of all work stages and roles of participants. If stakeholders are unclear about the process, do not understand who is responsible for what, and are unaware of the presale's objectives, misunderstandings can happen. For example, if a sales specialist performs the presale function, they will focus on closing the deal and maximizing the contract amount. Meanwhile, the project manager’s main task begins after presale, and they will be more concerned with risks, potential delays, and resources. This gap in approaches often leads to conflicts.

Sales managers aim for quick and profitable deal closure, while other team members seek to minimize risks and issues. In such cases, presale managers may try to accelerate processes, skip steps, or underestimate timelines. Common conflict points include:

Deal timelines and key steps;

Solution formatting, calls, and Q&A sessions;
Preparation and presentation materials;
Effort and risk assessment;
Role distribution and resource planning;
Gathering and preparing case studies and examples.

How to Minimize Conflicts?

To reduce conflicts and establish effective collaboration between sales and operational teams, it is essential to properly organize the presale process. Clearly define core stages, time estimates for each, and responsible persons. Optimizing this process may take about six months but will provide a solid foundation. It is also important to document the roles of all participants and, where possible, link KPIs to financial results.

Main roles and responsibilities during presales:

Business Analyst — analyzes the client’s current business, identifies problems, and formulates proposals for their solution.
Technical Lead (Tech Lead) — responsible for technical project implementation. Defines technologies and resources needed, provides architecture, and estimates timelines and effort.
Project Manager — organizes team work, manages contract-related tasks, interacts with the client, and participates in negotiations.
Sales Specialist — communicates with the client, clearly conveys proposals, and guides the client toward deal closure. It’s crucial that the client perceives the salesperson as the main contact; otherwise, confusion may arise regarding who is managing the process and which questions to ask.

For effective cross-departmental interaction, it is vital to agree in advance on what information needs to be shared and what rules should be followed. For example, project managers need the following data:

Project scope

What is included and what is not;
Who participates in presale, and what access rights the Tech Lead and team have to client information;
All existing documents, instructions, tools, and resources .

For presale managers:

Conduct productive syncs with the team and client representatives;
Strictly adhere to deadlines: timing at the presale stage is crucial. Even a delay of a couple of days can cause the project to lose to competitors who act faster;
Organize all presale stages carefully, with a clear plan, responsible persons, deadlines, and requirements.

Another challenge can arise if the presale role is performed by a sales specialist unfamiliar with technical questions or hesitant to consult experts. This approach often results in errors that can have serious consequences, damaging the entire team’s work.

Conclusion

Presale is a vital stage that lays the foundation for successful project delivery. The Pre-Sale Manager plays a key role in creating accurate proposals that consider all client needs, team capabilities, and potential risks. Instead of relying solely on a sales manager, it is important to involve a specialist with both commercial and technical expertise—especially in larger companies. This approach helps avoid problems later in the project and ensures its successful execution.

Ultimately, a Pre-Sale Manager is not just a “salesperson,” but a strategist who helps the company understand what the client truly needs and how best to achieve it.

I hope this information about presale has been helpful. Please leave a comment — does your company have a Presale role? Who performs this role? Do you understand its importance?

The Perfect Delivery: Flying Drones Will Change All the Rules of Modern Delivery!

Pro Project Managment — Tue, 07 Jan 2025 22:28:38 +0000

Imagine a morning where you wake up, make a couple of quick movements, and suddenly your breakfast, ordered through a mobile app, is flying right to your window! For me, the ideal delivery is when food is delivered by flying drones, allowing you to retrieve it without stepping outside your apartment. In this post, I’ll share how I envision this idea being implemented, the changes that are necessary, and the advantages it will bring to everyone.

Changes in the Ordering App

Developing a mobile app specifically for drone delivery will allow users to order with ease. Its graphical interface should be user-friendly and intuitive. Users should not only be able to enter a delivery address but also select a point in 3D space. We're not just talking about a flat map; we’re envisioning a spatial representation where anyone can choose the exact spot right in front of their window. This could take the form of a virtual model where users can “drag” the delivery point and also specify the height in space.

Cargo Securing and Weight Control

To ensure the reliable delivery of any product, it’s crucial to carefully consider how cargo will be secured to the drone. I believe the best approach is to use cables and special mounts that will ensure secure attachment and loading. The drone will have a weight control mechanism. If the weight exceeds the limit, the app should send a notification to the user that the cargo exceeds the allowable weight. This guarantees safe delivery by the drone.

Artificial Intelligence and Delivery Point Selection

AI should also be integrated into the delivery system to significantly enhance user experience. The AI will analyze user addresses and suggest optimal delivery options, leveraging big data from previous deliveries. If a user lives on a high floor, the system can propose delivery points near their apartment windows for maximum convenience. Furthermore, the AI can assist users in selecting a specific point in 3D space, taking height into account.

Impact on Building Architecture

Drone food delivery will also influence the architecture of buildings. Soon, we might see kitchens and other rooms equipped with special platforms for drones. This could become a new trend in construction. Just imagine: kitchens without gas stoves and sinks, where all food is delivered straight through the window!

Innovations in Restaurants and Cafés

Restaurants and cafés will be able to adapt their processes to the new system. They can use dedicated street points for drones, where food will wait for its “passenger,” similar to how goods are currently loaded for ground drones. Advanced cafés and restaurants might create “Fly Through” spots, where staff can load food into the drone without stepping outside the establishment. This will not only streamline the process but also enhance operational efficiency and, consequently, profitability.

Advantages of Transporting with Flying Drones

Speed of Delivery: Air drones will quickly deliver goods to customers, especially in large cities where traffic congestion is commonplace.
Eco-friendliness: Modern flying drones operate on electricity instead of gasoline, reducing pollution and CO2 emissions compared to traditional vehicle deliveries.
Job Creation: The implementation of this technology will require specialists in development, design, engineering, and IT, creating new jobs and increasing employment and salaries in the IT sector, which have been declining recently.
Advancements in Technology: Mass delivery via air drones will boost the development of modern technologies, such as advanced AI, enhanced navigation systems, more energy-efficient batteries, and much more.
Convenience for Users: Delivery right to your window is convenient and saves time, allowing you to spend more time with family or work, while also minimizing unnecessary contact, which is especially relevant during the pandemic.

In Conclusion

Flying drones for the delivery of goods and food in Moscow and other megacities is no longer a dream. This technology is not a fantasy but a reality that is already waiting for mass adoption. We stand on the brink of a new era where drones will not only simplify our lives but also create new high-paying jobs and change the landscape of modern cities!

Share your thoughts on the future of drone delivery in the comments! What would you like to add, and how do you envision future deliveries? Don’t forget to like this post—it inspires me to write more content! Thank you for your support!

🚀 Visualize Success: BPMN is the Key to Efficient Business Process Management! Plus, a Masterclass on Using Miro Board! 🌟📈🎉

Pro Project Managment — Sun, 05 Jan 2025 15:46:44 +0000

In today's fast-paced business environment, companies must continuously optimize their internal processes to enhance efficiency, reduce costs, and improve customer satisfaction. BPMN (Business Process Model and Notation) is a standardized graphical notation designed for modeling business processes.

The Business Process Management Initiative (BPMN.org) was established and is supported by the Object Management Group, following their merger in 2005. The latest version of BPMN is 2.0 (2.0.2).

Key Concepts of BPMN 2.0

The primary goal of BPMN 2.0 is to provide an easily understandable and collaborative representation of business processes, facilitating communication among business analysts, developers, and business users. Through visualization, BPMN helps all parties understand the structure, actions, and relationships between processes.

A BPMN process represents any business process visualized using this notation. Each process consists of various elements represented on the diagram with unique symbols. BPMN elements serve both as graphical representations and descriptions of the business process itself.

The notation includes the following key graphical components:

Pools and Lanes
Activities
Gateways or Divergences
Events
Flows
Artifacts

A BPMN diagram illustrates the sequence of work actions and the flow of information. Modeling allows for the description of any business process. BPMN highlights areas for improvement and models ways to adapt to new conditions.

In BPMN 2.0, elements are represented by specific icons. The creators of this system aimed to provide a comprehensive set of icons that allows for clear visualization of a wide variety of business process diagrams. Now, let’s take a look at the fundamental elements that are essential for any business process diagram.

Pools and Lanes

Within pools, there are lanes that conveniently represent different roles, such as within a single department. In this case, the pool would represent the department, while the lanes would represent the employees. There can be a flow of actions between operations within the lanes. For example, the lanes might represent different systems where specific actions occur and data is transferred from one system to another.

Activities

The term “Activity” refers to a unit of work performed during the execution of a business process (which can be implemented in a CRM if needed). In BPMN (Business Process Model and Notation), activities can be either simple (tasks) or complex (sub-processes). There are several categories of simple activities that differ based on the conditions for their execution:

Multiple Occurrences: Activities can occur multiple times within a single business process. The same operation may happen simultaneously for all elements within a customer's order.
Repetitive Activities: These are tasks that are performed repeatedly as long as a specific condition remains true.

It is important to emphasize that modern Business Process Modeling Notation offers a wide range of operation types, far beyond what is depicted in the image below, which only shows the basics.

Gateways

Gateways are elements that define the branching and merging of workflow paths. BPMN describes seven types of gateways, with two being considered the most fundamental:

Exclusive Gateway: This type of gateway is used to create alternative paths in a process or to merge incoming control flows.

Parallel Gateway: This gateway is employed to form parallel paths without evaluating any conditions or to merge incoming flows while synchronizing parallel branches of the process.

These two types of gateways are sufficient for constructing processes of any complexity. Other types of gateways detailed in Business Process Modeling Notation (BPMN) allow for the creation of more compact process diagrams. However, many experts question the benefit of this, as it is unlikely that individuals without professional training will be able to understand such diagrams.

Moreover, using more complex types of gateways can lead to confusion and difficulties in interpreting processes. Therefore, it is essential to maintain a balance between the level of detail in a model and its clarity for users. Choosing the right types of gateways not only aids effective modeling but also enhances communication among process participants.

Activities

This is another key component of the business process model. Events determine the direction of the process. They represent what has happened—conditions or circumstances upon which we base our actions. Events serve as the "if" condition in an "if-then" sequence: If it’s raining outside, then you need to take an umbrella. In this case, the rain is the event.

Here are examples of events types:

Notification Event: For example, receiving an email, among others.
State Event: Such as "it's raining," "a friend called," etc.
Temporal Event: Marks the expiration of a specific period.

Each of these event types plays a crucial role in managing business processes, ensuring flexibility and adaptability. Proper interpretation and handling of events enable companies to respond swiftly to changes in both the external and internal environments. Ultimately, effective event management contributes to more efficient resource allocation and increased overall productivity within the organization.

Flow (Connections)

Flow represents a sequence of actions indicated by arrows. The flow element specifies which action should be performed after another.

Control Flow: This is unaffected by conditions and does not pass through gateways, making it uncontrolled.

Conditional Control Flow: Indicates that subsequent actions in the process will follow a specific path only if a given condition is met. If the conditional control flow originates from a process, a diamond shape is added at the base of the arrow. If it comes from a gateway, the diamond is not used.

Default Control Flow: Used to indicate that the process will proceed along a specified path only if none of the given conditions are met.

Message Flow: Demonstrates the interaction between processes—showing the transfer of messages or objects from one process to another or to an external reference.

Association: Used to visualize the relationship between flow elements and artifacts that are not flow elements.

Artifacts

Artifacts in BPMN are elements that do not have a direct impact on the execution of a business process. They include various documents, data, and information.

The group of objects serves to consolidate graphical elements of one category, which enhances the overall comprehension of the diagram.

Text annotations are intended for supplementing the diagram with comments and explanations that improve its readability.

The information about the data being processed within the process.

Here are some great tools for creating BPMN: Draw.io, Camunda Modeler, Bizagi Modeler, Bpmn.io, as well as my favorite tool, Miro, which is perfect for all Scrum Masters in modern IT for visualizing meetings.

Example of BPMN diagrams

Top 10 Tips for Drawing BPMN Diagrams in Miro

Use Templates: Take advantage of BPMN templates in Miro to save time and minimize errors.
Follow BPMN Standards: Familiarize yourself with the key BPMN elements such as events, activities, and gateways.
Group Elements: Utilize groups to simplify the structure and navigation of your diagram.
Add Comments: Embed comments to clarify complex elements or processes.
Use Color Coding: Applying colors helps to distinguish between different types of tasks or processes.
Save Versions: Regularly save changes to avoid data loss.
Incorporate Icons: Use icons to visualize ideas and processes effectively.
Embrace Minimalism: Avoid overcrowding the diagram with unnecessary details.
Simplicity is Key to Clarity.
Utilize Change History: Use the "Change History" feature to track edits made to the diagram.
Sticky Notes: Employ sticky notes for meetings and discussions.

Effective Meetings: Demonstrating BPMN in Miro!

Schedule a Meeting: Ensure all participants have access to Miro (you can add a link to it in the agenda of the scheduled meeting in Google Calendar) and are aware of the meeting.
Use Co-editing Features: During the meeting, display the diagram in real-time and make adjustments on the fly.
Gather Feedback: Encourage colleagues to share their ideas and suggestions for improving the diagram.
Make Changes: As discussions unfold, update the diagram in Miro immediately so everyone can see the changes reflected.
Ease of Sharing: You can easily share a link to the diagram for participants to edit. Use the screen-sharing feature in Zoom or another video call platform to showcase the diagram, and leave comments on the board after the meeting!

Masterclass on BPMN in Miro: Practical Application

To view the BPMN diagram for IT support management, click here.

Jira Configuration Made Easy: First Time Tips for New Project Managers!

Pro Project Managment — Sun, 05 Jan 2025 01:53:45 +0000

Stepping into the world of project management can feel overwhelming, especially when tasked with configuring tools like Jira for your new IT project. Whether you're developing a custom CRM, a website, or a mobile application, getting Jira set up efficiently is crucial for your project's success. Here’s a straightforward guide to help you navigate the initial stages of configuring Jira effectively.

Understand Your Project Methodology

Before diving into the setup, it's essential to decide on the project management methodology you will be using. Most IT projects typically follow either Scrum or Kanban. If your project involves frequent changes—such as launching a new mobile app—Scrum may be the ideal choice. In contrast, for more established projects, Kanban could be a better fit. Knowing your approach will guide your configuration decisions.

Step-by-Step Setup Guide

1. Create Your Project

Log into your Jira site. If you’re part of a company, you might already have access; otherwise, you can create a free account for teams of up to 10 members. On the top navigation bar, select the dropdown menu under "Projects" and click "Create Project."

2. Choose Your Template

Select a project template that aligns with your chosen methodology. Options include Scrum, Kanban, and Bug Tracking. For smaller teams, opt for "Team Projects," as Company Projects require more administrative oversight.

3. Configure Task Statuses

Navigate to the project settings and customize the statuses for your tasks. Common statuses might include New, To Do, In Progress, In Review, and Done. Tailor these statuses to suit your project's specific needs.

4. Design Your Workflow

Enter the workflow editor and create a flow for task transitions. For instance, you might want to add an intermediate status like "Take to Work" between New and To Do. This flexibility allows your team to visualize task progression and manage rejections effectively, such as moving a task from In Review back to To Do if it fails to meet acceptance criteria.

5. Integrate with Version Control

If your team uses GitHub or Bitbucket, integrate these repositories into your Jira setup. Go to the "Products" section and select "Add Product" to connect Bitbucket. This step ensures seamless collaboration and code management.

6. Add Your Team

Create your team within Jira by naming it and inviting members via their email addresses. Encourage everyone to fill out their profiles and add profile pictures to foster a sense of community.

7. Kickoff Meeting

With your Jira site configured, hold a kickoff meeting with your team. Present how to use Jira, discuss task flows, and encourage open feedback on the setup. This collaboration will enhance everyone's understanding and comfort with the tool.

Ongoing Management

If you're following Scrum, remember to create and initiate sprints to track progress. For Kanban, monitor work through your task board, moving tasks across columns as they progress. As your project evolves, continuously refine your workflows and explore Jira's automation features, dashboards, and custom filters to keep your project on track.

Conclusion

Setting up Jira doesn't have to be daunting. By following these steps and fostering an open dialogue with your team, you'll establish a robust framework that sets your project up for success. Embrace the process, gather feedback, and don’t hesitate to tweak your configurations as your project evolves. Happy project managing!

A Complete Guide to Creating Tasks in Jira: From Epics to Bugs 🌟

Pro Project Managment — Tue, 31 Dec 2024 14:43:37 +0000

In today's project management landscape, utilizing tools like Jira is essential for the successful operation of teams. However, to make the most of this tool, it’s crucial to understand how to create tasks correctly and what information needs to be included so that developers have all the necessary details for their work.

Types of Tasks in Jira

Let’s start with the main types of tasks you will encounter in Jira: Epic, Story, Bug, Task, and Sub-task.

Epic: An Epic is a large user story that cannot be completed within a single iteration and can be broken down into smaller tasks. Epics often require development that spans multiple sprints, especially if you are following the Scrum methodology.
Story: A Story is a component of a larger Epic that the team can complete in one sprint. It describes functionality from the end-user's perspective and is typically formatted as: "As a [type of user], I want to [do something], so that [I can achieve a goal]."
Task: A Task is a technical job performed by a team member. Generally, technical tasks are not collaborative but are necessary for the successful completion of Epics.
Sub-task: A Sub-task is a portion of a Story or Task that describes the minimal amount of work for one team member. Breaking down tasks into Sub-tasks allows for more accurate effort estimation.
Bug: A Bug is a task that captures errors that need to be analyzed and fixed. Sometimes, it can be challenging for the product owner to understand the nature of the bug, and priorities may be misaligned, leading to a decline in product quality.

How to Fill Out Tasks

When creating a User Story, it’s important to follow a specific structure. The title should reflect the essence of the task. For example: "Creating a Sales Report: Analyzing Monthly Data to Optimize the Product Range." The description should provide information that helps the team better understand the task. Examples of user stories might look like this:

As a website administrator, I want to create a sales report so that I can analyze monthly sales and make inventory decisions.
As a BA, I can segment website visitors into two groups and conduct an A/B test on the homepage to increase conversion.
As a content manager, I can add an interactive chart to any blog page to make posts more engaging.

Additionally, it’s helpful to include acceptance criteria for each user story. For example, for the first case, these could include:

The report includes data for the specified period.
The report can be exported in CSV format.
The report displays data categorized by product type.

It is also advisable to use labels for better task filtering. Specify the priority and estimate for the task (e.g., 5 story points) and add it to the first sprint.

If necessary, break tasks down into Sub-tasks so that different team members can begin their work on separate aspects of the task. For instance, a designer might work on the design, while a front-end developer implements the layout. If you have a single developer, breaking it down into stages may not be essential, but it can still aid in estimation.

Helpful Tips

For Epics, add links to documentation and technical specifications to ensure the team has a shared understanding.
When creating a bug, try to answer the questions [What] [Where] [When] and include screenshots or videos for clarity.
We recommend using the Lightshot tool for screenshots, which allows for annotations.
If you are working in Scrum, estimate the task during planning and fill in the estimate together with the team.
Use the AI assistant in Jira to help draft tickets – this can simplify the process.

How do you create tickets for your projects? Share your thoughts in the comments and feel free to share screenshots!

Implementing New Business Processes in CRM: A Step-by-Step Plan for Large Companies

Pro Project Managment — Tue, 31 Dec 2024 14:18:03 +0000

Hello, dear readers! Today, I want to share my experience in implementing new business processes within a CRM system in a large organization with over 500 office employees and a total workforce of several thousand.

This post will be useful for project managers, business analysts, and team leaders. I hope my checklist of 7 steps will help you avoid common mistakes and make the process more efficient.

Step 1: Kickoff Meeting

First and foremost, hold a kickoff meeting with the department head. It’s crucial to gather all requirements for the new business process and ask additional questions for clarification. Don’t hesitate to propose your solutions, and sketch out a preliminary process diagram during the meeting to visualize your ideas.

Step 2: Develop the Business Process

Once you have collected the information, move on to creating the business process in a process editor. Simultaneously, test the process as individual sections are completed. This will help identify shortcomings at an early stage and make necessary adjustments.

Step 3: Test Runs

After completing the development, conduct several test runs that closely mimic real conditions. This is a great opportunity to demonstrate the process to the department head and gather their feedback. Make adjustments as needed.

Step 4: Instructions and Educational Materials

When the business process is ready, create detailed instructions for its use, including video materials. It’s important to add this information to your knowledge base so that all employees can easily access it.

Step 5: Discussion with Department Employees

Hold a meeting with department employees to discuss why this business process was adopted, its benefits, and usage rules. Be sure to give employees the opportunity to ask questions and discuss any issues that arise.

Step 6: Launch the New Process

After a successful meeting, proceed with the launch of the new business process. It’s essential that all employees are prepared and understand their roles.

Step 7: Support and Improvement

Create a support chat including all employees who will use the new process. Be ready to answer any questions and assist with problem-solving. After a week, when the questions have been resolved, you can close the chat if it's no longer needed, reminding everyone about the availability of video instructions in the knowledge base.

Implementing new business processes is not only a challenge but also an opportunity for growth and optimization for your team. I hope my experience will be helpful and inspire you to make successful changes in your organization.

Wishing you success in your work!

Reverse Engineering Business Requirements: Tips for Senior Business Analysts 🌟

Pro Project Managment — Mon, 30 Dec 2024 19:50:17 +0000

What is Reverse Engineering (RE)? RE is the process of extracting information from an existing solution and presenting it in a needed format. In this context, a business analyst requires information that will serve as a foundation for formulating requirements.

This methodology is not explicitly covered in the IIBA’s knowledge base, BABOK, but it falls under the technique of Document Analysis.

The task of Reverse Engineering always arises within the context of another task. Businesses are not inherently interested in the RE process itself, as it can be an expensive operation that requires the involvement of various stakeholders and a high level of skill from the business analyst. Often, the focus is placed on the analyst's hard skills. Therefore, before embarking on RE, it's crucial to clearly define the scope of the task and its objective.

Scenarios for Reverse Engineering

Clarifying requirements to support existing functionality.
Joining a project that involves adding or significantly altering an existing solution.
Planning a project to completely update an outdated system.
The client has an old system, and you are introducing your ready-made product for a complete replacement.
Developing requirements for data migration between two active systems.
Formulating requirements for the integration of existing solutions.
Conducting a detailed analysis of a competitor’s product to understand its useful features and how they work.

All of these tasks share one key characteristic: to execute them successfully, it’s essential to have up-to-date system requirements (ideally). Based on a reliable and profound understanding of the existing system (As-Is), the business analyst can formulate a new set of requirements.

Information Sources for Reverse Engineering:

Interviews with technical experts: This may include developers, testers, and customer support staff.
Hands-on experimentation: If you can interact with the system by pressing various buttons, this can be a great source for both description and hypothesis testing.
Data analysis: Data-driven decision-making can significantly aid in the decision-making process.
Detailed examination of data structures.
Source code analysis (if available).
Interviews with business stakeholders and end-users: Observing their interactions with the product may be the only available method in some cases.
Understanding the domain specifics.
Existing documentation: Unfortunately, this is often outdated or missing.
Ticket analysis in Jira, Asana, Trello, or other systems.

Key Considerations for Reverse Engineering Business Requirements

Avoid over-comprehensive documents: They are often unnecessary, especially if they exist in isolation. Our goal is to solve the task within the context of new requirements. Perfectionism is often misplaced here.
All sources can be misleading: Even code and databases can be deceptive. It’s crucial to leverage all available means to verify information. Unfortunately, verification takes time, and deadlines for analysts are often tight, forcing them to choose where to invest their time and what to accept at face value.
Be cautious with the level of detail: The reasons are the same as above.
Distinguish how the system functions from how it should function: You can maintain a parallel list of changes to be added to the backlog, but restored requirements should be documented in the As-Is format.
Clearly define and monitor the scope of your research: It’s easy to get caught up in trivial details or veer off course. What constitutes “trivial” depends on the criticality of the original task that prompted the requirements reconstruction.
Plan for future work with the reconstructed requirements: If further work is anticipated, rather than just a one-time reconstruction, consider establishing a process for updating system documentation.

Understanding User Groups from BABOK and Their Communication Nuances

End Users: They work directly with the solution and can demonstrate its usefulness, but:

They may not be interested in discussing the current state of the system as it’s their routine.
They often jump to their ideal working scenarios.
They poorly organize their knowledge and may forget both frequent and rare operations.
They know only their part of the process, which can lead to mixing facts with assumptions.
There might be just one person in the department responsible for a specific function, leading to information silos.

Operational Support: This group can provide useful information as they collect data from tickets, but:

They often fail to notice their own mistakes, associating themselves with the system.
Their process knowledge may be superficial.
They are often passive and reluctant to engage in dialogue.
As technical specialists, they may delve deeply into details.

Sponsor: The person responsible for the budget can clarify strange steps in the business process, but:

They rarely delve into details and quickly forget about problems after they are resolved.
They receive summarized information, which can lead to outdated perceptions.
They are busy, making them hard to reach.

Customers: The clients of the business using the solution:

They are rarely involved and available for interviews.
They may misinterpret how the system works and show low interest.
They face similar issues as end users.
Regulators: Initially not very useful, but they can point out constraints that others may not be aware of.

Supplier/Vendor: They use pre-built components provided by third parties. They can be an additional source of information about implementation details, but:

They rarely engage and may sabotage the project if their solution is disconnected.
They may be absent due to their company exiting the market for other reasons.

Unfortunately, there is no magic button that resolves all the aforementioned issues. Overall, two recommendations can be made:
Cross-check information.
Verify against other sources.
Utilize techniques like "Observation" and "Document Analysis."

Gathering Information from Technical Specialists

Implementation Subject Matter Experts / Testers:
This group can be a valuable source of information about the implementation process, but they have their nuances. Technical specialists typically do not delve into business details. They understand how the system works but often struggle to explain why it’s necessary. This hinders their ability to assess the relevance of functionalities. In their environment, it is often claimed that a certain function is needed, supported by documentation, existing dependencies, and user bug reports related to both the function and adjacent aspects. Relying solely on the opinions of this group can easily reproduce the old behavior of the system with all its shortcomings, including misalignment with actual business needs.

Project Managers / Business Analysts:
Generally, this is a stable group of specialists positioned at the intersection of technical and business stakeholders, helping align needs with their implementation. Don’t expect them to provide in-depth technical descriptions, but they can narrate the project story, adding to the overall understanding of the context. They typically possess an up-to-date list of issues and a good grasp of the political landscape within the company. However, it’s essential to avoid excessive dependence on their support and involvement in corporate intrigues.

Reverse Engineering Business Requirements: Tips for Senior Business Analysts 🌟

Pro Project Managment — Mon, 30 Dec 2024 19:23:04 +0000

This methodology is not explicitly covered in the IIBA’s knowledge base, BABOK, but it falls under the technique of Document Analysis.

Scenarios for Reverse Engineering

Clarifying requirements to support existing functionality.
Joining a project that involves adding or significantly altering an existing solution.
Planning a project to completely update an outdated system.
The client has an old system, and you are introducing your ready-made product for a complete replacement.
Developing requirements for data migration between two active systems.
Formulating requirements for the integration of existing solutions.
Conducting a detailed analysis of a competitor’s product to understand its useful features and how they work.

Information Sources for Reverse Engineering:

Interviews with technical experts: This may include developers, testers, and customer support staff.
Hands-on experimentation: If you can interact with the system by pressing various buttons, this can be a great source for both description and hypothesis testing.
Data analysis: Data-driven decision-making can significantly aid in the decision-making process.
Detailed examination of data structures.
Source code analysis (if available).
Interviews with business stakeholders and end-users: Observing their interactions with the product may be the only available method in some cases.
Understanding the domain specifics.
Existing documentation: Unfortunately, this is often outdated or missing.
Ticket analysis in Jira, Asana, Trello, or other systems.

Key Considerations for Reverse Engineering Business Requirements

Avoid over-comprehensive documents: They are often unnecessary, especially if they exist in isolation. Our goal is to solve the task within the context of new requirements. Perfectionism is often misplaced here.
All sources can be misleading: Even code and databases can be deceptive. It’s crucial to leverage all available means to verify information. Unfortunately, verification takes time, and deadlines for analysts are often tight, forcing them to choose where to invest their time and what to accept at face value.
Be cautious with the level of detail: The reasons are the same as above.
Distinguish how the system functions from how it should function: You can maintain a parallel list of changes to be added to the backlog, but restored requirements should be documented in the As-Is format.
Clearly define and monitor the scope of your research: It’s easy to get caught up in trivial details or veer off course. What constitutes “trivial” depends on the criticality of the original task that prompted the requirements reconstruction.
Plan for future work with the reconstructed requirements: If further work is anticipated, rather than just a one-time reconstruction, consider establishing a process for updating system documentation.

Understanding User Groups from BABOK and Their Communication Nuances

End Users: They work directly with the solution and can demonstrate its usefulness, but:

They may not be interested in discussing the current state of the system as it’s their routine.
They often jump to their ideal working scenarios.
They poorly organize their knowledge and may forget both frequent and rare operations.
They know only their part of the process, which can lead to mixing facts with assumptions.
There might be just one person in the department responsible for a specific function, leading to information silos.

Operational Support: This group can provide useful information as they collect data from tickets, but:

They often fail to notice their own mistakes, associating themselves with the system.
Their process knowledge may be superficial.
They are often passive and reluctant to engage in dialogue.
As technical specialists, they may delve deeply into details.

Sponsor: The person responsible for the budget can clarify strange steps in the business process, but:

They rarely delve into details and quickly forget about problems after they are resolved.
They receive summarized information, which can lead to outdated perceptions.
They are busy, making them hard to reach.

Customers: The clients of the business using the solution:

They are rarely involved and available for interviews.
They may misinterpret how the system works and show low interest.
They face similar issues as end users.
Regulators: Initially not very useful, but they can point out constraints that others may not be aware of.

Supplier/Vendor: They use pre-built components provided by third parties. They can be an additional source of information about implementation details, but:

They rarely engage and may sabotage the project if their solution is disconnected.
They may be absent due to their company exiting the market for other reasons.

Unfortunately, there is no magic button that resolves all the aforementioned issues. Overall, two recommendations can be made:
Cross-check information.
Verify against other sources.
Utilize techniques like "Observation" and "Document Analysis."

Gathering Information from Technical Specialists

Diving into the Use of Use Cases in JIRA🌟

Pro Project Managment — Mon, 30 Dec 2024 15:38:17 +0000

In the modern world of software development, it's crucial to understand how users interact with a system. This is where the methodology known as Use Case or scenario usage comes into play. Let’s take a closer look at what it is and how to properly create use case scenarios.

Use Case includes the following elements:

1.Actors

These represent roles or external entities that interact with the system. Actors can be users, other systems, or devices. For example, in an online ordering system, an actor might be a "Customer" or an "Administrator."

2.Preconditions

These describe the states and conditions that must be met before the use case scenario begins. For instance, for an order placement scenario, a precondition might be: "The user must be logged into the system."

3.Main Flow

This is the sequence of steps that need to be followed to achieve the goal of the scenario. For example, in the order placement scenario, the main flow includes selecting a product, adding it to the cart, entering payment information, and confirming the order.

4.Alternative Flows

These describe possible deviations from the main scenario. For instance, if the chosen product is out of stock, the system might suggest selecting a different item.

5.Postconditions

These describe the state of the system after the scenario has been completed. For the order placement scenario, a postcondition might be: "Order information has been saved in the database."

6.Exceptions

These outline errors or unexpected situations that may occur during the execution of the scenario. For example, if there is an error processing the payment, the system should notify the user and prompt them to try again.

Example of a Use Case in JIRA: Password Reset

Title: Password Reset

Actors: Registered User

Preconditions: The user must have access to the registered email address.

Main Scenario:

The user clicks the "Forgot Password?" button.
The system prompts for the email address.
The user enters their email address.
The system sends password reset instructions to the provided address.
The user follows the instructions and sets a new password.

Alternative Scenario: If the user enters an incorrect email address, the system displays an error message.

Postconditions: The new password is successfully set.

Exceptions: If there is an error sending the email, the system notifies the user about the issue and suggests trying again.

Conclusion

So, should you use use cases or user stories in your work? How do you decide which is best for your team? If you have extensive experience with agile projects and teams, you know the undeniable value of user stories. They convey what the user or client wants to achieve, ensuring that teams always consider user needs. However, despite the fact that use cases may seem a bit outdated, they can provide the necessary context regarding how the system is used. They describe how users interact with the system, answering many questions in advance to assist in managing complex processes.

Moreover, it wouldn't be very agile to dismiss a solution simply because you haven't tried it before. 😉

Task Decomposition: Make Projects Manageable and Successful – for Business Analysts, Scrum Masters, and Project Managers! 🏆💪💥

Pro Project Managment — Sun, 29 Dec 2024 16:16:48 +0000

Task decomposition is the process of breaking down a complex task or project into smaller, manageable, and understandable subtasks. This approach simplifies task execution, structures it better, and reduces the stress associated with completing it.

Task decomposition can be performed both during the planning stage of a new sprint and throughout the sprint's execution by breaking down requirements for subsequent iterations. However, the latter approach is generally more preferable. It is advisable not to tie decomposition to a specific sprint, in order to come to its planning with a prepared backlog divided into user stories.

In such a situation, having a reserve of decomposed requirements offers the following advantages:

Firstly, we do not limit ourselves in choosing tasks for the sprint (we can work only with those tasks that have already been decomposed).
Secondly, during planning, we do not need to spend time on breakdown, allowing the team to focus on forming the sprint considering all priorities, discussing dependencies, and details of the requirements' implementation.
Thirdly, the meeting will be more productive, and all team members will be actively engaged. Remember that meetings should be effective and positive, so the team looks forward to them rather than perceives them as a boring routine.

Two Main Approaches to Decomposition

There are two basic approaches to decomposing large tasks into user stories: "horizontal" and "vertical" decomposition.

In the so-called "horizontal" decomposition, tasks are divided based on the type of work (functions) performed and the components used. In this approach, a large task is broken down into parts where a developer takes on one share of responsibilities, a tester takes another, a technical writer another, and so on. It is important to note that each of these parts does not lead to a completed result on its own; successful delivery of the finished functionality requires collaborative execution of all interrelated tasks by all process participants.

On the other hand, the "vertical" approach to decomposition focuses on identifying smaller tasks, functions, and features so that each user story can be implemented and completed independently of others. In this case, various roles may be involved in the development process, and several modules and systems may be utilized, providing greater flexibility and speed in implementing functionality.

The vertical decomposition approach aligns more closely with Agile principles and is much more effective for several key reasons:

When using the "vertical" approach to decomposition, each task becomes available for implementation, testing, and demonstration to clients or users, making it understandable and measurable, unlike the more abstract "technical" tasks that arise from "horizontal" decomposition.

Within the "vertical" decomposition framework, each final user story has explicit business value, simplifying the process of comparing and prioritizing such tasks.

Since solving tasks organized by the "vertical" principle involves specialists with different roles, they can more easily identify potential problems, dependencies, and risks that may arise during the work's execution.

Techniques for Decomposing Requirements

Method 1: Stage-wise Breakdown of Business Processes

This approach suggests breaking down a large task related to a business process into smaller, independent components and stages. For this method to be effective, it is important to identify sequential steps that can be performed independently. For example, if there is a requirement in the backlog to implement an online purchasing function, the stages could include:

Logging into the personal account
Viewing items in the "cart"
Generating an invoice
Sending the invoice by email
Payment via various methods: credit card, transfer, etc.
Each of these stages can be formatted as a separate user story. Thus, we break down an extensive business process into components, allowing us to set priorities and better understand the process as a whole, including possible dependencies between stages.

Method 2: Separation into Positive and Negative Scenarios

Every functionality involves a primary use case that leads to the expected outcome, but deviations leading to negative consequences are also possible. This method suggests identifying scenarios that can lead to a successful or unsuccessful result. For example, for the online store purchase function:

Positive scenario: the user logs in and successfully completes the purchase.
Negative scenario 1: attempt to purchase without logging in.
Negative scenario 2: insufficient funds in the account to complete the transaction.
Negative scenario 3: account locked after several failed password attempts.
This approach allows for the proactive identification and planning of how to handle possible errors and exceptions.

Method 3: Breakdown by Rules and Conditions

In contrast to the previous method, this method emphasizes logical branches of the process based on various rules. For example, for the purchase function, rules might include:

Minimum purchase amount.
Additional payment options for exceeding a certain amount.
Automatic order cancellation after 2 days without payment.
Each of these conditions can be formatted as a separate task, helping to identify important constraints and simplifying the implementation process.

Method 4: Separation by Types of Operations

Many functional requirements correspond to standard operations such as create, read, update, and delete (CRUD). For example, for managing product cards in an online store, we can identify:

Create: adding a new product.
Read: viewing product descriptions.
Update: editing product information.
Delete: removing a product from the store.
This breakdown allows for a clear definition of necessary operations and their priorities.

Method 5: Decomposition by Platforms and Operating Systems

This method involves breaking down requirements based on the platform or operating system. For example, for the payment function in a web application, tasks can be identified for various devices:

Personal computers
Tablets
Smartphones
Different operating systems: Windows, iOS, Android.
This approach helps to define priority development directions.

Method 6: Separation by Data Types and Parameters

Some functions may handle various types of data or parameters. For example, for the search function in an online store, we can identify:

Search by product name.
Search by product number.
Search using regular expressions.
This decomposition allows for a clear definition of acceptable parameters and easy management of requirements.

Method 7: Separation by Roles and Access Rights

Different user groups may have different access rights and perform various functions. For example, in an online store, these may include:

Owner: create and delete products.
Administrator: edit descriptions and interact with customers.
Customer: view and purchase products. This breakdown helps understand what functionalities are necessary for each role and prioritize their implementation.

Method 8: Decomposition by Test Scenarios

This method breaks down functionality based on test cases that need to be verified to check the successful operation of functions. For example, for the function of adding a product to the "cart," the following test scenarios might be identified:

The product is available for purchase.
The product is reserved by another user.
The product is out of stock. This approach allows for the integration of various decomposition techniques and creates clear tasks for development and testing.

Each of these decomposition methods helps to better structure requirements and contributes to more effective development in an Agile environment.

Advantages of Task Decomposition:

Improved Understanding: Breaking down large tasks (or user stories) into smaller parts allows the team to better understand what exactly needs to be done. Smaller tasks are easier to conceive and discuss.
Better Estimation: The team can more accurately estimate the time and effort required to complete smaller tasks, improving planning and resource management (ensures great Planning Meetings using Fibonacci numbers or T-Shirt Sizes).
Manageability: Smaller tasks are easier to plan and control. The team can more accurately estimate the time and labor resources needed to complete each task.
Increased Transparency: When tasks are broken down into smaller parts, it becomes easier to track progress and identify issues at early stages. This allows the team to respond quickly to changes.
Enhanced Flexibility: In Scrum, changes in requirements often occur, and task decomposition allows the team to adapt more flexibly to these changes by adjusting their plans and priorities.
Improved Quality: Smaller tasks enable the team to focus on the quality of each individual part, which can lead to a higher quality final product.
Encouragement of Collaboration: Task decomposition can foster more active collaboration within the team, as participants can work on different parts of the same task simultaneously.
Gradual Integration: Breaking tasks down into smaller parts allows the team to integrate and test functionality in stages, reducing risks and improving stability.

I hope this information is useful to you! If you have any questions or suggestions, please leave comments. I would be happy to assist you with personal advice on IT, business analysis, Scrum, or project management!

🌍 Join the Senior Project Management Community and Help Create the PMBOK® Guide 8! 📖✏️🌟

Pro Project Managment — Sun, 29 Dec 2024 14:19:17 +0000

Hello, dear colleagues and fellow project management enthusiasts! I am excited to share with you an incredible opportunity that has the potential to transform your perspective on project management and allow you to contribute to its future. From December 20, 2024, to January 19, 2025, the public comment period for the 8th edition of the PMBOK® Guide will take place.

This is your chance to influence one of the most recognized resources in the field of project management—one of my personal favorites as a Senior Project Manager!

Why is the PMBOK® Guide being updated?

The landscape of project management is evolving rapidly. We are witnessing the rise of artificial intelligence, sustainable practices, and adaptive methodologies as key success factors in today’s dynamic environment. In all our recent projects, AI has played a crucial role. The 8th edition of the PMBOK® Guide reflects these changes and offers updated approaches and tools that will help us stay at the forefront of our field.

What distinguishes the 8th edition from the 7th?

The 7th edition marked a significant shift by adopting a principle-based approach. The 8th edition builds upon this foundation by incorporating enhanced coverage of process groups and processes. With updated terminology, project lifecycle content, and new insights on AI, PMOs, and procurement, this edition will empower you to understand and apply the latest project management principles in real-world scenarios.

Who develops the PMBOK® Guide?

The PMBOK® Guide is created by the community for the community. The development team for the 8th edition consists of 24 experts from 18 countries, each contributing their unique experiences and perspectives. Anonymity ensures objectivity and fairness, allowing everyone to focus on their expertise without external influence.

What are the goals of the standards and guides?

The PMBOK® Guide comprises two complementary components:

The Standard for Project Management: a globally recognized foundation defining key principles and processes.
The Guide to the PMBOK®: a practical manual providing tools and examples for applying these principles across various contexts.

What happens during the comment period?

From December 20, 2024, to January 19, 2025, the project management community is invited to review the draft and provide feedback. Your insights will help shape the next edition to meet the needs of practitioners worldwide. Additionally, there will be a second comment period later in 2025 specifically for the Standard, giving you another chance to share your thoughts.

How can you submit your comments for the 8th edition of the PMBOK® Guide?

To leave your feedback, simply visit the comment page. If you don’t have an account yet, be sure to register. For those with existing accounts, you can add your comments directly in the document. Instructions are available there as well. The document is hosted on the Konveio editor. After reviewing the new version, if you find a section where you’d like to comment, just click and fill out the fields: Section, Requested Change, Line Number, Comment Type, Rationale for Change, and then hit "Post comment." Congratulations—you’ve made your contribution! You will see a confirmation message with details about your Requested Change and Rationale for Change. A short video with step-by-step instructions is also available for your convenience.

Don’t miss this opportunity to be a part of this significant process! Visit the PMI public comment page, review the draft, and share your thoughts. Your contribution can have a monumental impact on the future of project management!

Also, don’t forget to like this post and subscribe to the blog—it inspires me to create more content for you!

Looking forward to your valuable insights!

🚀 How to Pass the PSM I Certification in 2024-2025: Tips from My Recent Experience ✨ 📈🏆

Pro Project Managment — Sat, 28 Dec 2024 13:40:21 +0000

I’m excited to share some valuable tips that helped me successfully navigate the PSM I certification recently. If you're looking to achieve this certification in 2024, these strategies can significantly enhance your preparation and boost your confidence.

1. Master the Scrum Guide

First and foremost, you must thoroughly study the Scrum Guide. It's not enough to memorize definitions; you need to truly understand the concepts. This understanding will empower you to articulate any definition in your own words and explain any actions taken in Scrum.

For easy access, here’s the link to the latest Scrum Guide: Scrum Guide 2020.

2. Complete the Scrum Open Assessment

I highly recommend taking the Scrum Open Assessment until you consistently score between 95-100%. This assessment consists of 30 questions, with some variations each time you take it. It's a great way to familiarize yourself with the exam format and reinforce your knowledge.

You can find it here: Scrum Open Assessment.

3. Explore the Product Owner Open Assessment

Additionally, I suggest studying and completing the Product Owner Open Assessment until you reach a score of 95-100%. This will deepen your understanding of the Product Owner role within Scrum and provide you with more insights for the exam.

Check it out at: Product Owner Open Assessment.

4. Invest in a Mock Exam

For around $15, consider purchasing a mock PSM I exam from MPlaza. This practice exam closely simulates the actual testing conditions, including a timer. It will challenge you to answer based on your understanding of Scrum.

You can find it here: MPlaza Mock Exam.

Insights for the PSM I Certification 2024-2025

a) During my exam, I noticed that approximately 15-20% of the questions were identical to those from the Scrum Open Assessment, and a few questions were directly from the Product Owner Open Assessment. Therefore, it’s crucial to excel at these assessments before taking the certification exam. The remaining 80% of the questions were different, but if you truly understand Scrum rather than simply memorizing the guide, you will find them manageable.

b) You will have 60 minutes to answer 80 questions, so pay careful attention as you read and answer each question. If you're unsure about a particular question, mark it and return to it if time permits.

c) Before the exam, ensure your workspace is quiet and free from distractions. A stable internet connection and a fully charged laptop are essential for a smooth testing experience. While I didn't encounter any identical questions from MPlaza, I still recommend it as a tool for gauging your understanding of Scrum and simulating the actual testing conditions.

d) Keep in mind that the PSM 1 exam fee in 2024 is $200, so passing on your first attempt is crucial. If you follow the first four steps, you’ll be well-prepared to tackle the exam with confidence.

e) There are plenty of additional resources available, like Quizlet and other bloggers, but my advice is to be cautious. Many of these may reference outdated information from the 2017 Scrum Guide, which may not align with the latest version. Additionally, some free resources may contain incorrect answers or irrelevant content.

f) As a final tip, I finished my exam with about 5-10 minutes to spare, which I used to double-check any questions I was unsure about. Given the time constraints, I don't recommend Googling questions during the exam, as you may run out of time to complete all of them. Once your time is up, you will immediately receive your results and certification!

Good luck on your journey to obtaining the PSM I certification in 2024-2025! With the right preparation and mindset, you can achieve your goal.