How to be a successful project manager

To become a good project manager, you need to understand the problems, opportunities, and expectations faced by the Project Manager, understand that the project team will have conflicts, and find out who is the stakeholder, understand the four criteria for judging the project's success: budget, progress, performance standards and customer satisfaction. We also need to build a harmonious team and act as a coach, leader, and conflicting arbitrator. You cannot stop because of Project setbacks, or be comfortable with the status quo. You are a leader and a soldier throughout the project implementation. So what should a successful project manager do? The author summarizes some experiences in the implementation of software projects and hopes to share them with readers.

 

How to organize development teams

How to build a software development team depends on the personnel to choose from, the needs of the project, and the needs of the Organization. This article describes the strategies of various teams in the project implementation process.

An effective software project team is composed of people with various roles. Each member plays one or more roles. One person may be responsible for project management, while others actively participate in system design and implementation. Common Project roles include: analysts, planners, database administrators, designers, Operation/support engineers, programmers, project managers, project sponsors, Quality Assurance engineers, demand analysts, topic experts (users), and testers.

As a project manager, How do you organize a project team? Is vertical, horizontal, or hybrid? A team organized in a vertical solution consists of multiple teams, each of which plays multiple roles. Teams organized in a horizontal solution are composed of experts. Each member plays one or two roles. Teams organized in a hybrid solution include both multiple teams and experts.

An important consideration is the nature of the people that can be selected. If most people are versatile, you often need a vertical solution. Similarly, if most people are experts, you need a horizontal solution. If you are introducing new people, your project and organization should be prioritized even if they are all contractors. This article describes the vertical, horizontal, and hybrid solutions for forming a team organization, and points out their respective advantages and disadvantages. An important significance of this discussion is that your team organization should have a tacit understanding between the means used to manage the project; any method of detuning may cause problems in the project.

Vertical team organization

A vertical team consists of multiple teams. Use cases are assigned to individuals or groups, and then use cases are implemented from the beginning to the end.

Advantages

● Smooth end-to-end development based on a single use case.
● Developers can master a wider range of skills.

Disadvantages

● A multi-user is usually a consultant who is very expensive and hard to find.
● A multi-user usually does not have the specific technical expertise required to quickly solve specific problems.
● Topic experts may have to work with several developers to increase their workload.
● The levels of all multiple faces vary.

Successful Factors

● Each Member shall work in accordance with a set of common standards and guidelines.
● Good communication is required between developers to avoid the implementation of public functions by different groups.
● The public and consensus-building architecture should be established in the project as soon as possible.

Horizontal team organization

The level team is composed of experts. Such teams process multiple use cases at the same time, and each member is engaged in their own Aspects of the use case.

Advantages

● High-quality completion of all aspects of the project (requirements, design, etc.
● Some external teams, such as users or operators, only need to interact with a small number of experts who know their exact requirements.

Disadvantages

● Experts are often unable to realize the importance of other professions, leading to a lack of connectivity between various aspects of the project.
● The information required by "backend" personnel may not be collected by "front-end" personnel.
● Project management is more difficult because the priorities, opinions, and requirements of experts are different.

Successful Factors

● Good communication is required between team members so that they can understand their respective responsibilities.
● It is necessary to develop the workflows and quality standards that experts must follow to improve the efficiency of transferring to other experts.

Hybrid team organization

A hybrid team is composed of experts and multiple teams. Multiple users continue to operate the entire development process of a use case, and support and process the experts from various parts of multiple use cases to work together.

Advantages

● Advantages of the first two solutions.
● External teams only need to interact with a small number of experts.
● Experts can concentrate on what they are good.
● The implementation of each use case is consistent.

Disadvantages

● Has the disadvantages of the first two solutions.
● It is still difficult to find multiple faces.
● Experts still cannot recognize the work of other experts and can't collaborate well, though it should be adjusted by multiple experts.
● Project management is still very difficult.

Successful Factors

● Project Team members need good communication.
● Public architecture needs to be determined.
● Public processes, standards, and standards must be properly defined.

Project team morale is a factor for project success

The success of most projects defines how the project is completed on time, whether it is within the budget, and whether it meets users' needs. However, it is very difficult to find good software professionals today, not to mention retaining them. In this case, it is also necessary to extend the definition of project success to include the morale of the project team. After trying to complete a software project, you may lose important developers because they are overwhelmed. This may meet the short-term needs of the Organization, but it is certainly harmful for the long-term benefits of building an efficient software department. An important measure of project success is the morale of the team after the project is over. At the end of the project, do the members of the project team think they have learned some knowledge from their own experiences and do they like to work for the project, and whether you want to participate in the next project of the Organization.

Project planning skills

Project planning skills are essential for today's software developers. Here are some suggestions to help you effectively plan the next project.

Recognize that confidence comes from the planning process, not the plan itself.

Creating a project plan forces you to consider how to build your system before writing code-to reduce project risks, because you have considered various policies and methods and have selected the most meaningful one. Your goal should not be just to generate a plan; it should be a practical plan that you can manage your project based on.

Software Process Promotion Plan Development

Each software process has a different set, which includes the activities of the Organization team and the techniques commonly used in project planning. For this reason, the Rational Unified Process (RUP)-based project planning is different from the oosp project planning, and the oosp project planning is also different from the extreme programming (XP) project planning. Different processes have different plans.

Starting with a coarse-grained plan

When the project is about to begin, a coarse-grained plan should be developed to determine the project's advanced activities and expected milestones. Coarse-grained plans are organized into iterations-depending on the size and nature of the project, each iteration usually occurs between three to eight weeks (preferably four to six weeks ). Some of these iterations will be concentrated in the initial stage of the project, while many iterations will be concentrated in the functional development of the entire application, and some iterations are concentrated in converting your system into a product.

The Implementer should be a scheduler.

The best person to create a project plan is the person responsible for implementing the plan. When a plan is created by one person and implemented by another person, if the project cannot be completed on time or exceeds the budget, they will not trust the plan, but may blame it. That is to say, everyone involved in the project should invest in the development and development of the project plan.

Don't forget "what you shouldn't forget"

The plan should not only reflect the "real" work of demand design, modeling, programming and testing, but also the auxiliary activities (but still important), including: vacation and statutory holidays, training and education, project management activities (such as planning and personnel management), overhead (such as system on-site time, meetings, and email reply), Architecture Definition, tested system rework, system delivery, and reuse-related activities (such as generalization ).

Compile any ideas and constraints into the document

Make assumptions when planning, such as getting a new release of the application server in time, or developers who are familiar with the technology and skills you are using. At the same time, you will work under some constraints, such as the mandatory deadline or resource restrictions that affect the plan. These assumptions and constraints are documented so that you can remember some of your previous "unusual" decisions when you update your plan at any time during project implementation.

Recognizing different resources means different plans

A team of ten experienced developers has created far more results than a team of ten beginners. To be more practical, your plan must reflect the actual conditions of resources available for the project.

Create a realistic plan

The project team must trust the purpose, valuation, and timetable of its project. To do this, you must plan it in real time to avoid planning beyond what you can understand. Ignorance can be tolerated only when you plan to study unknown issues.

Only plan valuable things

The IBM developerworks website provides many best practices for your project. However, depending on the nature of the project, not all of these technologies will suit your unique situation. To put these best practices simply as tools you place in the project management toolkit, you can use them as needed.

Use project management tools as appropriate

Some project management tools, such as Microsoft Project, provide important functions, such as Gantt Chart (Activity Schedule) development, comparison between planning and actual results, and PERT chart (network chart) development, task definition, task relevance definition, task resource allocation and resource balance. All of these seem to be a good idea, and they are usually a good idea-but they require a lot of effort to create and maintain and rarely provide practical value to the project team. Indeed, it has made some project managers feel productive. Indeed, advanced management prefers to see you have a plan. However, no line of code is generated by all the activities. Planning is a valuable activity, but investing a lot of time to create a planning chart is usually not a valuable activity.

Exercise caution when applying technical solutions to Management Problems

Are you sure you want to use technology to solve the problems encountered in the project? This article is adapted from the fifth chapter of process patterns by the author. Scott Ambler suggests improving management, rather than new technologies. It may be your solution.

There is no point to resolve the problem by changing management practices using the latest deployment technology (see the squanded computer in reference ). In fact, you should not owe the benefits of all business processes to software projects that support these changes. Without these new software or hardware, you may enjoy the same benefits.

Identifying technical solutions as non-technical problems is a common mistake that often repeats in the information technology field. This frequently-occurring error is called apply technical solution to non-technical problem (applying technical solutions to non-technical problems) self-process anti-pattern (process anti-pattern is a method that has been proved to be ineffective in actual operation ).

Technical solutions are only applicable to solving technical problems. For example, the concept of "Network Computer" is still a hot fashion in the computer industry. The basic concept is to replace PC with a network computer, so that organizations can greatly reduce their spending on supporting computer hardware and software.

Studies show that if training and support costs are included, the average annual spending on supporting a personal computer is between $5,000 and $30,000. Network Computers (also called Java terminals, because they only run programs packaged into Java Byte Code) will theoretically reduce costs because they only require simple maintenance and support. Despite a lot of advertising efforts, so far, the sales volume of network computers has been poor. On the surface, network computers seem to be trying to solve the problem technically. However, when you think about this, the problem has actually become one of the management problems.

Some organizations spend $30,000 a year to support computers not because of personal computers, but because of misuse of personal computers. These organizations do not allow qualified professionals to install public configurations, but allow users to select and install their own software. Once users are in trouble, the Organization's expenses soar. In addition, the file format is incompatible. Without a public software suite, users have to waste a lot of time converting files between different software versions provided by the same vendor or between different software versions provided by different vendors. For a similar reason, hardware training and support become more difficult when users buy their own devices.

In this case, the problem is related to the process: improper management of personal computer hardware and software. Therefore, it is doubtful whether the technical solution of network computer can solve the problem. Technical solutions are applicable to technical issues, management solutions are applicable to management issues, and process solutions are applicable to process problems. After talking about all the content, I really mean to use the right tools at work.

Demand-based planning policies: prioritized

A successful Project Team recognizes that it cannot create all the requirements equally. Therefore, they need to prioritize and operate in this order.

Some requirements are more important than others. For example, for online banking, the support for inter-account transfers is much more important than the elbonian language version stated by the bank every month. A successful software team will first focus on building the most important features to meet the key features of the user's needs as much as possible, and those critical features will be left for future processing. Demand sorting enables your team to make the greatest contribution to the Organization's software profit. However, to effectively prioritize requirements, several factors must be taken into account: Business Value, delivery cost, delivery date, delivery complexity, and risks (see the tip "control risks: "), the relationship with other requirements, and the time when the requirement is required.

Possible priority range

As long as the priority is clearly defined and the application is consistent, it is irrelevant to use the priority range. General priority levels include:

● High, medium, and low

● Required, conditional, and optional

● Numeric (e.g., 1, 2, 3)

How to prioritize requirements

You should allow authorized individuals or groups to establish and confirm the priority assigned. Priority sorting is usually a negotiation process, which involves many project participants, this includes your users, user management, advanced management, developers, operators, and support departments.

Most project teams will be organized into a "configuration Control Board (CCB) "-sometimes referred to as the" Change Control Board "or" project planning Steering Committee "-It consists of key and knowledgeable participants in the system. Generally, the group holds regular meetings to determine the priority and assignment of any new requirements (for system release or duplication of existing development results ).

Why are requirements prioritized?

The demand sorting list is a key factor in the input and project demarcation process. In the early stages of the project, one of the most difficult tasks needs to be realized is not to be able to deliver every function required by the project participants. Project Scope defines the scope to be delivered by the project team. This is important because it helps avoid "out of scope", that is, additional requirements for project progress. The defined scope of projects enables you to negotiate whether you have the responsibility to deliver new requirements, determine the rationality of the new demand for the increase in delivery date/cost and discuss whether the demand should be delivered in subsequent releases. If a definite scope is missing, the project team will bear the risk of being unable to deliver, because it is often necessary to add "one more function" to the project being built ".

Planning iteration: develop detailed plans in a timely manner

When the project continues, you need to plan the iterative activities to be implemented in detail. In today's ever-changing environment, it is of no value to make detailed plans several months or even several years in advance, but you can plan for the next few weeks (the time span of typical iterations) detailed planning is successful.

A common and incredible approach to project planning is to start with a rough project planning (see "project rule Tips"), that is, development from the beginning of the project, then, it develops slowly when completing various iterations of the project. As the project progresses, you need to update the entire rough project plan to reflect the actual results of recent efforts and the planning details of the next (or two) iterations that your team will continue to work on. These steps should be performed in the careful planning of a single iterative development.

Implement authenticity check

Ask and answer some questions to start planning in detail: Is the project still running as planned? Does your method still make sense? Is your team composed of the right people? Do you still have support from fund managers? If the answer to any of these questions is correct, you need to solve the problem. This may mean that new (and very short) iterations bring your team back to normal. It is of no value to make a big plan for a difficult project.

Identifies a detailed task

At the beginning of the project, the architecture and transfer iteration only list the tasks to be implemented. However, to plan iterations, you must evaluate the requirements that have been specified for it (see "demand-based planning policies "). As the project develops, you will have a better understanding of individual needs. You may find that the original requirements that need to be changed to the iteration are originally meaningful. A new requirement may have been identified and added; the requirement may have been extended or reduced; or the priority may have been changed. For whatever reason, you will find that you need to redefine the content to be implemented in this iteration. Identify the task to be implemented as required.

Identify task relevance

Some tasks depend on other tasks. For example, you must write the source code before deploying it. Development of test cases can begin before coding. The test of the actual code must wait until some code has been written (although perhaps not all code. The problem is that some tasks can only start after other tasks are completed. Some tasks must wait until another task starts. Some tasks cannot be completed, until another task is completed; some tasks cannot be completed until another task starts.

Balance Resources

The important thing to note is that each person can only process so many tasks at a time, and there is only so much time on the day of work. This concept is called resource balancing and ensures that task allocation is reasonable. It is very likely that 10 tasks cannot be completed at 10% of the time specified, and those who specify 50% of the time to complete 5 tasks cannot complete these tasks. The best way to ensure realistic planning is to involve execution plan personnel in plan development.

Keep iteration short

The iteration cycle should be kept relatively short. More than eight weeks of iteration should be divided so that you can quickly deliver the software to users. Because you are trying to make up for the work skipped in previous iterations (such as document preparation), or because your requirements are increasing and no new iterations are added to reflect this fact, so the growth of iteration length is a trend when the project progresses. Performing authenticity checks and following their results will help you keep the iteration cycle short.

Parallel Development

It is always an effective way to conduct different parts of the system in several sub-teams at the same time, especially for the development of system vertical segments. Parallel development can greatly shorten the product market time, which is an important factor in today's highly competitive market, although it is at the cost of increasing coordination. A common architecture, a shared knowledge horizon, a common development practice, regular team meetings, and a shared workspace make parallel development possible.

Source: original users