Some software project managers (PM) do not know how to develop a project plan. They do not even plan but only use the schedules given to them by customers. They do not develop vision for the project or estimate the project efforts. Their logic is requirements always change, why bother to plan something that will change? They do not understand the purpose or the benefits of a project plan.
Showing posts with label Software Project Management. Show all posts
Showing posts with label Software Project Management. Show all posts
Tuesday, September 25, 2012
Thursday, September 20, 2012
Project management experience
Dear Professor,
When graduated I always thought that I could write code for the rest of my career. It was until my third year that I realized that I could do more than just writing code and the training in your courses at CMU opened new opportunity for me. When my company had an opening in software project manager, I applied and got it without any difficulty. I have been working as project manager for five years and this short letter is about the things I have learned as project manager. Since you often asked working graduates to share experience with current students, I hope that my letter may benefit some students who someday will manage software project.
Sunday, September 2, 2012
Software project management
A project vision is the direction of the project. It is the “Compass”
that guides project team to move forward to the same direction. The
vision must be communicated to team members at the beginning of the
project to give the team a view about the project and how they must work
together to achieve that vision.
Some project managers issue the vision to the team then move on to other activities. In that case, the team may lose sight of the vision because they are always busy with their own works. Good project managers will not letting anything distract them from the vision because if they become distracted, the project may not be successful as expected. Team members work best when they have all the information they need to do their tasks but they also need information about how their tasks fit into the vision of the project. Being able to put their tasks into a bigger context provides motivation and helps members make better decisions.
Some managers do not know how to plan projects or create vision. They do not even know how the project should be done so they do not want to share their plans with anyone. They feel insecure about their positions so they often hide behind “Busy works” and avoid talking with team members. When team member asks, they always find excuse that they are so busy and do not have time. The most used excuse is “Having to go to meetings with other managers” so attending meetings become their daily work. These managers do not trust their teams but consider them as “subordinates” rather than people who are capable of doing the work. When people lack a vision or information, they fill in the gaps with their own beliefs and sometime rumors. Rumor gives misinformation and often consumes a lot of time to correct it.
Project managers need to know about status or progress of the project so they can report to higher managers. Without a vision or project plan to monitor against, many rely on individual meetings where each member reports to them instead of team meetings. In this case, members only provide a fraction of the information a manager needs to know. Many important issues remain hidden in this status meeting. For example, team member may be reluctant to admit that they have problems, or facing difficulties, or talk about the information that a project manager needs to know. Without a clear picture of the project, these managers cannot make good decision. Sometime, they do not want to report bad status so they let things happen and when it is getting worst, they blame their own people.
A good project manager always monitors activities to ensure that every action is done to achieve the vision. He collects and evaluates data on schedule and budget to identify risks and respond to them quickly. He has weekly meeting with the team to share progress and keep everyone focus on their assigned tasks. He knows that software projects often have problems; team members always face obstacles such as dealing with changes; not having enough time for tasks etc. Therefore, he must eliminate any distractions to keep the team focus on what they do.
Good project manager does not work alone but always involve the team into project activities. At the beginning of the project, he brings the team together to discuss the objectives of the project. He asks team members for their opinions to get the best suggestions. By engage the team early; he creates a sense of teamwork that allows members to feel that their suggestions are important. When team members feel they are important, they work hard to achieve the vision which lead them to overcome obstacles and strives for success.
Some project managers consider themselves as “Bosses” and project management is about giving orders. This is a mistake. When they order team member to do something, they are not giving the person the opportunity to think about what to do or how to do it. In this case, team member is limited to do exactly as manager tell them to. They will develop habit of only wait for instruction and become reactive instead of active. They cannot analyze tasks or learn anything new and that is why many projects are late. They are late because team members are waiting for managers tell them what to do and without the direction, nothing will happen. A good manager does not give orders but instructions. Giving instructions is not telling somebody what to do, but telling them exactly what he wants to be done. In this case, team member must think on how to do it. Rather than mechanically just doing a task, team member will have to think about the process, the procedure and all the details on how to do it. In this case, they must learn to think and be more active in improving their skills. Good team members always think when they are given an instruction. They always identify different ways of doing the task and consider which way is better. When team members come up with their solution, they feel good. It encourages them to learn more and it improves their confidence in what they do. If something happen to their work, they will be confident to defend it themselves. Giving instructions is the best solution that works well for most software developers.
Some project managers issue the vision to the team then move on to other activities. In that case, the team may lose sight of the vision because they are always busy with their own works. Good project managers will not letting anything distract them from the vision because if they become distracted, the project may not be successful as expected. Team members work best when they have all the information they need to do their tasks but they also need information about how their tasks fit into the vision of the project. Being able to put their tasks into a bigger context provides motivation and helps members make better decisions.
Some managers do not know how to plan projects or create vision. They do not even know how the project should be done so they do not want to share their plans with anyone. They feel insecure about their positions so they often hide behind “Busy works” and avoid talking with team members. When team member asks, they always find excuse that they are so busy and do not have time. The most used excuse is “Having to go to meetings with other managers” so attending meetings become their daily work. These managers do not trust their teams but consider them as “subordinates” rather than people who are capable of doing the work. When people lack a vision or information, they fill in the gaps with their own beliefs and sometime rumors. Rumor gives misinformation and often consumes a lot of time to correct it.
Project managers need to know about status or progress of the project so they can report to higher managers. Without a vision or project plan to monitor against, many rely on individual meetings where each member reports to them instead of team meetings. In this case, members only provide a fraction of the information a manager needs to know. Many important issues remain hidden in this status meeting. For example, team member may be reluctant to admit that they have problems, or facing difficulties, or talk about the information that a project manager needs to know. Without a clear picture of the project, these managers cannot make good decision. Sometime, they do not want to report bad status so they let things happen and when it is getting worst, they blame their own people.
A good project manager always monitors activities to ensure that every action is done to achieve the vision. He collects and evaluates data on schedule and budget to identify risks and respond to them quickly. He has weekly meeting with the team to share progress and keep everyone focus on their assigned tasks. He knows that software projects often have problems; team members always face obstacles such as dealing with changes; not having enough time for tasks etc. Therefore, he must eliminate any distractions to keep the team focus on what they do.
Good project manager does not work alone but always involve the team into project activities. At the beginning of the project, he brings the team together to discuss the objectives of the project. He asks team members for their opinions to get the best suggestions. By engage the team early; he creates a sense of teamwork that allows members to feel that their suggestions are important. When team members feel they are important, they work hard to achieve the vision which lead them to overcome obstacles and strives for success.
Some project managers consider themselves as “Bosses” and project management is about giving orders. This is a mistake. When they order team member to do something, they are not giving the person the opportunity to think about what to do or how to do it. In this case, team member is limited to do exactly as manager tell them to. They will develop habit of only wait for instruction and become reactive instead of active. They cannot analyze tasks or learn anything new and that is why many projects are late. They are late because team members are waiting for managers tell them what to do and without the direction, nothing will happen. A good manager does not give orders but instructions. Giving instructions is not telling somebody what to do, but telling them exactly what he wants to be done. In this case, team member must think on how to do it. Rather than mechanically just doing a task, team member will have to think about the process, the procedure and all the details on how to do it. In this case, they must learn to think and be more active in improving their skills. Good team members always think when they are given an instruction. They always identify different ways of doing the task and consider which way is better. When team members come up with their solution, they feel good. It encourages them to learn more and it improves their confidence in what they do. If something happen to their work, they will be confident to defend it themselves. Giving instructions is the best solution that works well for most software developers.
Prof John Vu
Carnegie Mellon University
Original source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1414
Original source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1414
Early Project work
Even today the numbers of software projects failure are still high.
Somehow software managers continue to rush into projects without even
thinking why past projects failed. According to an industry research, a
majority of project managers do not receive adequate trainings or know
how to plan a project. Many project managers confused a project plan
with a project schedule. A schedule is only a small part of a project
plan; it usually takes the form of tasks complete within a timeline. The
project plan is a roadmap providing guidance on the priority of
activities, the scope of work, the life cycle, the method and tools to
be used. It identifies customers, users, business strategy, quality,
risks, and how project costs and people will be managed.
Most projects fail due to bad requirements. This is the number one issue that causes scope change, which leads to more time and budget necessary to complete the project. That is why the job of requirements engineer or business analyst is important but few companies have these roles and few schools teaching this skills. Many companies expect that project manager should be responsible for project requirements and this is a big mistake. Requirements and customer relationships require a different skills and a lot of efforts and a busy project manager cannot adequately manage the project and the customers at the same time. This is also where some management textbooks failed to address. Bad requirements or poorly defined requirements will lead to a bad project plan. Since the project plan reflects the work, the resources, the budget, and time necessary to satisfy requirements, it is easy to see the importance of getting the right requirements and the project.
A requirements engineer is trained to work with customers and ensure agreement from all customers before project planning. A requirements engineer work with customers to collect their needs, understand their problems and document them in a requirements specification. Customers must review the requirements documents and approve before the planning phase of the project. Requirements engineer work with project manager to translate these requirements into the project scope statement, as well as the major components that will satisfy the scope. There are several essential elements that need to be included in the project definition:
• A description of the business problem and the solution to that problem
• A description of the benefits of the project (the business case)
• A definition of the project vision, goals, scope and budget
• A list of the major deliverables which, when delivered to customers will completely satisfy the requirements of the project)
• Project committed delivery dates
The project definition is the first part of project planning where the project team will be involved to breakdown these requirements into smaller components. The Work Breakdown Structure (WBS) is the foundation of the project plan. It is a hierarchical logical structure that represents all the work necessary to produce all the project deliverables.
By spending more efforts in the beginning, the project can avoid unnecessary requirements changes and project managers can organize the project to better chance of success.
Prof John Vu
Carnegie Mellon UniversityMost projects fail due to bad requirements. This is the number one issue that causes scope change, which leads to more time and budget necessary to complete the project. That is why the job of requirements engineer or business analyst is important but few companies have these roles and few schools teaching this skills. Many companies expect that project manager should be responsible for project requirements and this is a big mistake. Requirements and customer relationships require a different skills and a lot of efforts and a busy project manager cannot adequately manage the project and the customers at the same time. This is also where some management textbooks failed to address. Bad requirements or poorly defined requirements will lead to a bad project plan. Since the project plan reflects the work, the resources, the budget, and time necessary to satisfy requirements, it is easy to see the importance of getting the right requirements and the project.
A requirements engineer is trained to work with customers and ensure agreement from all customers before project planning. A requirements engineer work with customers to collect their needs, understand their problems and document them in a requirements specification. Customers must review the requirements documents and approve before the planning phase of the project. Requirements engineer work with project manager to translate these requirements into the project scope statement, as well as the major components that will satisfy the scope. There are several essential elements that need to be included in the project definition:
• A description of the business problem and the solution to that problem
• A description of the benefits of the project (the business case)
• A definition of the project vision, goals, scope and budget
• A list of the major deliverables which, when delivered to customers will completely satisfy the requirements of the project)
• Project committed delivery dates
The project definition is the first part of project planning where the project team will be involved to breakdown these requirements into smaller components. The Work Breakdown Structure (WBS) is the foundation of the project plan. It is a hierarchical logical structure that represents all the work necessary to produce all the project deliverables.
By spending more efforts in the beginning, the project can avoid unnecessary requirements changes and project managers can organize the project to better chance of success.
Original source:
Software development process
Many students are well trained in coding because a majority of their
time in university is focusing on coding but little on software
development process. Some students consider software development is an
individual work as they often receive individual assignments that each
must do and most assignments are about writing code. When they go to
work, many have a tendency to start coding immediately after receive an
assignment without fully understand the problem. As requirements often
change and they have to modify their code, they often make mistakes that
need fixing. The more they are fixed, the more complex their code
becomes. Eventually, it will be too difficult to understand the
structure of their code and their logic for testing or maintaining. If
developers just code and fix and do whatever they want then it would be
difficult to integrate their codes into a cohesive software product.
When students are trained on software development process, they understand that development is not just writing code and it is a team effort. Before starting, the team must have common understanding of the problems that they must solve, the project goals, the project activities where each team member has certain roles and responsibilities for the work. The software process is a roadmap that shows the team how to develop software from the high level to the detail level. There is a sequence order called the development life cycle where the entire process is dividing into several phases and each has certain roles, responsibilities for team members.
The software process starts with the understanding of the problem by verify the requirements with customers. Because customers often do not describe their needs clearly and often change their minds, the team must make sure what customers have asked for is what they needs. Only when these requirements are discussed and confirmed, the team begins to document them into the software requirements specification. By following the process, the team understands that the most common cause of project failure is unstable or poorly defined requirements and by having the requirements fully validated they can reduce the risk of changing requirements. After having customers approved the requirements document, the team starts their own discussion to make sure that every team member understands the problem well enough before they divide the project into smaller tasks that they must do.
By following the software process, the team defines the architect of the system with several components. Team members identify the interfaces between these components and then verify that all components can be traced back to the requirements so that the product will meet customer’s needs. This is important because any error in architecture can create issues during software integration in later phase. When a project moves from requirements phase to architecture phase, the team will discover that there are many “Derived requirements” that need to be done. Sometime the list of derived requirements is much more than the original requirements because an architect must consider things such as performance, scalability, usability, and maintainability that customers expect but do not ask for. Based on the architecture, the team selects software tools that they will use to build the system. At the same time, team members can begin to create a set of unit tests to be applied once they finish their code. Many developers do not think about testing until they finish coding but if they start to develop unit tests early during architecture phase, they can avoid many mistakes that often happen during design phase. By working on unit tests early, they understand the requirements better that help them to design the product better.
Design phase is where the internal logic of each component is organized. During this phase, team members work on the details of the data structures and the algorithmic of each component. In architect phase, the main focus is on identifying the components and the relationship of these components and how they interact with each others. During the design phase, the focus is on designing the logic for each of the components. Team members follow a process and using a set of techniques and guidelines such as problem partitioning and abstraction. The use of abstraction allows team members to focus one task at a time, without worrying about the details of other tasks. When all tasks are done, the team should follow a verification process by having a review of the design of each component. Typically, the project manager, the system architect, and the quality assurance must participate in the review to make sure that all works are done according to the plan, the overall system architect, and in compliance with the standard process.
When a design is fully verified and approved. Team members can start the implementation phase (Coding). Many people like to write code right away but if they follow the process, they must select data structure that meets the needs of the design; keep the logic structure as simple as possible; select meaningful variable names consistent with the standards. By select data structure first, then start with a logical organization of the coding structure they can avoid a lot of mistake often happen during this phase. After complete the first coding, team member must conduct a code walk through to review their code to make sure they follow the coding standard and their structures are consistent with the way the project is organized and planned. Each team member must perform unit tests and correct uncovered errors before move to the next phase.
In the testing phase, team members transfer their code to the testing team. Testing is the process of executing a program with the intent of finding error. A good test is one that has a high probability of finding error. By following the process, team members understand that tests should be planed early during architecture phase and all tests should be traceable to customer requirements. Testing should start in the smallest part and progress toward testing in the larger part and eventually the entire software product. (Unit test, Function test, Integration test, System test etc.)
When students are trained on software development process, they understand that development is not just writing code and it is a team effort. Before starting, the team must have common understanding of the problems that they must solve, the project goals, the project activities where each team member has certain roles and responsibilities for the work. The software process is a roadmap that shows the team how to develop software from the high level to the detail level. There is a sequence order called the development life cycle where the entire process is dividing into several phases and each has certain roles, responsibilities for team members.
The software process starts with the understanding of the problem by verify the requirements with customers. Because customers often do not describe their needs clearly and often change their minds, the team must make sure what customers have asked for is what they needs. Only when these requirements are discussed and confirmed, the team begins to document them into the software requirements specification. By following the process, the team understands that the most common cause of project failure is unstable or poorly defined requirements and by having the requirements fully validated they can reduce the risk of changing requirements. After having customers approved the requirements document, the team starts their own discussion to make sure that every team member understands the problem well enough before they divide the project into smaller tasks that they must do.
By following the software process, the team defines the architect of the system with several components. Team members identify the interfaces between these components and then verify that all components can be traced back to the requirements so that the product will meet customer’s needs. This is important because any error in architecture can create issues during software integration in later phase. When a project moves from requirements phase to architecture phase, the team will discover that there are many “Derived requirements” that need to be done. Sometime the list of derived requirements is much more than the original requirements because an architect must consider things such as performance, scalability, usability, and maintainability that customers expect but do not ask for. Based on the architecture, the team selects software tools that they will use to build the system. At the same time, team members can begin to create a set of unit tests to be applied once they finish their code. Many developers do not think about testing until they finish coding but if they start to develop unit tests early during architecture phase, they can avoid many mistakes that often happen during design phase. By working on unit tests early, they understand the requirements better that help them to design the product better.
Design phase is where the internal logic of each component is organized. During this phase, team members work on the details of the data structures and the algorithmic of each component. In architect phase, the main focus is on identifying the components and the relationship of these components and how they interact with each others. During the design phase, the focus is on designing the logic for each of the components. Team members follow a process and using a set of techniques and guidelines such as problem partitioning and abstraction. The use of abstraction allows team members to focus one task at a time, without worrying about the details of other tasks. When all tasks are done, the team should follow a verification process by having a review of the design of each component. Typically, the project manager, the system architect, and the quality assurance must participate in the review to make sure that all works are done according to the plan, the overall system architect, and in compliance with the standard process.
When a design is fully verified and approved. Team members can start the implementation phase (Coding). Many people like to write code right away but if they follow the process, they must select data structure that meets the needs of the design; keep the logic structure as simple as possible; select meaningful variable names consistent with the standards. By select data structure first, then start with a logical organization of the coding structure they can avoid a lot of mistake often happen during this phase. After complete the first coding, team member must conduct a code walk through to review their code to make sure they follow the coding standard and their structures are consistent with the way the project is organized and planned. Each team member must perform unit tests and correct uncovered errors before move to the next phase.
In the testing phase, team members transfer their code to the testing team. Testing is the process of executing a program with the intent of finding error. A good test is one that has a high probability of finding error. By following the process, team members understand that tests should be planed early during architecture phase and all tests should be traceable to customer requirements. Testing should start in the smallest part and progress toward testing in the larger part and eventually the entire software product. (Unit test, Function test, Integration test, System test etc.)
Prof John Vu
Carnegie Mellon University
Original source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1461
Original source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1461
Systemic software development
A software developer wrote to me: “We had several project failures.
Customers were angry but the project manager told us that they were
customer’s faults because they kept changing requirements. We are
starting a new project but I am afraid that we will make the same
mistake again. What can we do to avoid this problem? Please advice.”
Answer: If the customers keep changing requirements then you need to have a requirements engineer or business analyst to spend time with customers to obtain better requirements. This is an important role in software development but many companies do not pay attention. If the requirements are wrong than everything will be wrong no matter how good you can design or code. If your company does not have someone to do this then they should hire people who could do that job. When a project fails, your manager should not blame the customers but should identify the cause and fix it so it will not happen again. When customers are not happy then it is bad business. No company can survive if their customers are not happy. When a project is late, it takes more time, more money, and more efforts than previously planned. It means the company has to pay for these extra works and it means losing more money.
Changing requirements is a common problem in software industry. It is usually due to the lack of knowledge on software requirements. Many project managers think that they understand what the customers need and proceed to development without any customer validation. Many developers presume that they know all the features customers need then start design and code without any customer review. Progress is measured by each line of code built throughout the process until requirements begin to change. Fixing software after building is costly and time consuming. It often causes huge effort waste with hundreds of hours unproductive and hundred lines of code changes. This is why you need someone who understands requirements to work closely with customers to get the right requirements so you do not make the same mistake again.
There are different views of requirements. A manager’s view of requirements is often a high-level concept of a product or a business problem that must be solved. A user’s view of requirements is mostly the functions, the interface, and the navigation of screens. If the requirements are mostly functional, the project team may not understand various information hidden under the view of functionality. As a result, customer’s expectations may not be achieved.
To avoid this issue, project team must understand several views of requirements. The highest level view is the business requirements, representing the objectives of the customer. This is really the vision and the scope of your project. The second level view is the user’s requirements, which describe all the tasks that users must do when using the software. These are best captured in the form of use cases, which are scenarios of typical interactions between the user and the system. This is the architecture of the system with hardware, software interface and the navigation of screens. However, use cases alone do not provide enough detail for developers to know what to build. Therefore, you need the third level view or the functional view which derive from the use cases. The functional requirements clearly define specific things the software must do. This is the design of the system with each function clearly identified. However, there is another view called the non-functional view or the quality attributes which does not come from customer but from developers that deals with the quality of the software such as performance, efficiency, usability, or scalability etc.
By understand different views, developers can organize their work systematically to meet customers’ expectation and develop better software product.
Answer: If the customers keep changing requirements then you need to have a requirements engineer or business analyst to spend time with customers to obtain better requirements. This is an important role in software development but many companies do not pay attention. If the requirements are wrong than everything will be wrong no matter how good you can design or code. If your company does not have someone to do this then they should hire people who could do that job. When a project fails, your manager should not blame the customers but should identify the cause and fix it so it will not happen again. When customers are not happy then it is bad business. No company can survive if their customers are not happy. When a project is late, it takes more time, more money, and more efforts than previously planned. It means the company has to pay for these extra works and it means losing more money.
Changing requirements is a common problem in software industry. It is usually due to the lack of knowledge on software requirements. Many project managers think that they understand what the customers need and proceed to development without any customer validation. Many developers presume that they know all the features customers need then start design and code without any customer review. Progress is measured by each line of code built throughout the process until requirements begin to change. Fixing software after building is costly and time consuming. It often causes huge effort waste with hundreds of hours unproductive and hundred lines of code changes. This is why you need someone who understands requirements to work closely with customers to get the right requirements so you do not make the same mistake again.
There are different views of requirements. A manager’s view of requirements is often a high-level concept of a product or a business problem that must be solved. A user’s view of requirements is mostly the functions, the interface, and the navigation of screens. If the requirements are mostly functional, the project team may not understand various information hidden under the view of functionality. As a result, customer’s expectations may not be achieved.
To avoid this issue, project team must understand several views of requirements. The highest level view is the business requirements, representing the objectives of the customer. This is really the vision and the scope of your project. The second level view is the user’s requirements, which describe all the tasks that users must do when using the software. These are best captured in the form of use cases, which are scenarios of typical interactions between the user and the system. This is the architecture of the system with hardware, software interface and the navigation of screens. However, use cases alone do not provide enough detail for developers to know what to build. Therefore, you need the third level view or the functional view which derive from the use cases. The functional requirements clearly define specific things the software must do. This is the design of the system with each function clearly identified. However, there is another view called the non-functional view or the quality attributes which does not come from customer but from developers that deals with the quality of the software such as performance, efficiency, usability, or scalability etc.
By understand different views, developers can organize their work systematically to meet customers’ expectation and develop better software product.
Prof John Vu
Carnegie Mellon University
Original source:http://www.segvn.org/forum/mvnforum/viewthread_thread,1602
Original source:http://www.segvn.org/forum/mvnforum/viewthread_thread,1602
Sharing experience
Luis is a former student who graduated five years ago. Last week, he
came back to visit me so I asked him to share his experience with my
students. Following is his story:
“I graduated five years ago; I worked as a software developer for three years then got promoted to project manager. I have been managing software projects for over 2 years and had four projects; one did not do well but three were successful. I learned a lot during this short time so I would like to share my experience with you.
I am only 28 years old so I cannot say that I know a lot because there are much more to learn. Five years ago, I was just like you sitting in class and wondered what kind of job should I get when I graduate? I applied to several companies and hoped that maybe one would give me an interview. However, all of them called me for interview and I got three job offers. Each offered company had certain advantages and disadvantages so I asked my professor for advice. He told me: “Working for large company is secured and comfortable but you may not learn much and it takes time to move up. Working for small company is little risky but you will learn a lot. It is easier to move up in small company than big company.” With that advice, I decided to join a small software company that only had over three hundred people. Just like my professor said, there were lot of works and we were very busy but I did well. My code was always clean without any defect. My document was nicely written and I got along well with all team members. That got managers’ notice and just after three years, they promoted me to software project manager.
My idea of project manager is a person who understands how to solve problems for customers. That means you must work with customer to understand their needs then create a vision for the project and communicate it to everyone. It is about soft-skills of communication and relationship building. A project manager must know how to work with different types of people. You have to work with customers, who always want a lot of things but do not want to pay money. You have to work with the company owner who always put pressure on meeting schedule. You also have to work with developers who want to do everything perfect but do not pay much attention to the schedule. It is not easy if you do not have patience and motivation for success.
While good project manager should have technical skills but I found that I need business skills and soft-skills more. Since the school does not teach these skills, I must learn them by myself so I learned by watching how other people do that. I observed how other project managers deal with customers, managers and team members. Some did well but some did not. When I saw something that I did not know, I asked so I also learned by asking questions. I know that every project have a start date and an end date so I always focus to the end date and the product that I must deliver to customers. As technical person I know that I must solve problems but as a business person, I know that I must do that within a limited time too. I know that the success of the project does not necessarily come from just meeting schedule, but also having the best quality to meet customer’s expectation.
What have I learned so far in my short time? First I learned about how to work with people. Every project needs software developers who design, code, and test something. They also have to change and fix things. It is the people that make the project success so as a project manager I learned to treat them fairly. I did not consider myself as their boss but their friend. We work together as a team where everyone is equal. I always explained what I did and often asked them for opinion. When the project was under pressure, I actually help in code and test to whoever needs the most to keep thing progressing. I learned by treating people with respect and listen to their concerns. I know that if they like to work for me than I will have more chance for success. I can have good idea or good solution but without good people, I cannot do anything. I considered people skill is the most important skill over all.
There are many books about project management but no one can learn from books and become good manager. No one can be good manager if they do not fail at least few times when managing project. The first time you manage a project, you make many mistakes. Each time you do a new project, you also make many mistakes. It is the only way to learn important lessons and gain experience. We all begin our career full of ambitions and think we can do a lot but that is the naivety of youth. We do not know what is possible and what is impossible. Over time, you start learning more about project management when you practice it and this is where you really learn something. You start to understand what is important and what is not then making connections between things that seems not obvious to you but they are very important. You learn to listen to others for their opinions. Only by listening and willing to learn then you become better as a leader. When people are willingly to work for you, or even seek you out for advices then you are successful.
I was raised ethical, with high moral and socially conscious. My parents taught me to be honest with everything and create value that makes the world a better place. I know many young people only think about making money and nothing else and that is why they have difficulty in their lives. They often switch jobs to get a little more money. They jump from job to job without learning anything well enough. After few years, they have high salary but no skills then eventually they worry about losing job. I believe that by working hard and constantly learning new things, I can make myself more valuable to the company that I work for. I always have this attitude when I was a developer and I still feel exactly the same today.
I feel very proud to call myself a project manager. The fact is I am not perfect because I am still learning but at least the last three software projects that I managed were delivered to customer on time, within cost and without any problem. Many developers want to work for me and my team is growing from twenty to fifty people. My next project is challenging but that will not stop me from continuing my learning and come up with good results. My last advice: All of you have selected software as a field to study and this is a field with wonderful opportunities. All of you have a career that will last many years in the future. Developing career is a long journey so keep on learning, keep a positive attitude and be humble then you will do well.”
Prof John Vu
Carnegie Mellon University“I graduated five years ago; I worked as a software developer for three years then got promoted to project manager. I have been managing software projects for over 2 years and had four projects; one did not do well but three were successful. I learned a lot during this short time so I would like to share my experience with you.
I am only 28 years old so I cannot say that I know a lot because there are much more to learn. Five years ago, I was just like you sitting in class and wondered what kind of job should I get when I graduate? I applied to several companies and hoped that maybe one would give me an interview. However, all of them called me for interview and I got three job offers. Each offered company had certain advantages and disadvantages so I asked my professor for advice. He told me: “Working for large company is secured and comfortable but you may not learn much and it takes time to move up. Working for small company is little risky but you will learn a lot. It is easier to move up in small company than big company.” With that advice, I decided to join a small software company that only had over three hundred people. Just like my professor said, there were lot of works and we were very busy but I did well. My code was always clean without any defect. My document was nicely written and I got along well with all team members. That got managers’ notice and just after three years, they promoted me to software project manager.
My idea of project manager is a person who understands how to solve problems for customers. That means you must work with customer to understand their needs then create a vision for the project and communicate it to everyone. It is about soft-skills of communication and relationship building. A project manager must know how to work with different types of people. You have to work with customers, who always want a lot of things but do not want to pay money. You have to work with the company owner who always put pressure on meeting schedule. You also have to work with developers who want to do everything perfect but do not pay much attention to the schedule. It is not easy if you do not have patience and motivation for success.
While good project manager should have technical skills but I found that I need business skills and soft-skills more. Since the school does not teach these skills, I must learn them by myself so I learned by watching how other people do that. I observed how other project managers deal with customers, managers and team members. Some did well but some did not. When I saw something that I did not know, I asked so I also learned by asking questions. I know that every project have a start date and an end date so I always focus to the end date and the product that I must deliver to customers. As technical person I know that I must solve problems but as a business person, I know that I must do that within a limited time too. I know that the success of the project does not necessarily come from just meeting schedule, but also having the best quality to meet customer’s expectation.
What have I learned so far in my short time? First I learned about how to work with people. Every project needs software developers who design, code, and test something. They also have to change and fix things. It is the people that make the project success so as a project manager I learned to treat them fairly. I did not consider myself as their boss but their friend. We work together as a team where everyone is equal. I always explained what I did and often asked them for opinion. When the project was under pressure, I actually help in code and test to whoever needs the most to keep thing progressing. I learned by treating people with respect and listen to their concerns. I know that if they like to work for me than I will have more chance for success. I can have good idea or good solution but without good people, I cannot do anything. I considered people skill is the most important skill over all.
There are many books about project management but no one can learn from books and become good manager. No one can be good manager if they do not fail at least few times when managing project. The first time you manage a project, you make many mistakes. Each time you do a new project, you also make many mistakes. It is the only way to learn important lessons and gain experience. We all begin our career full of ambitions and think we can do a lot but that is the naivety of youth. We do not know what is possible and what is impossible. Over time, you start learning more about project management when you practice it and this is where you really learn something. You start to understand what is important and what is not then making connections between things that seems not obvious to you but they are very important. You learn to listen to others for their opinions. Only by listening and willing to learn then you become better as a leader. When people are willingly to work for you, or even seek you out for advices then you are successful.
I was raised ethical, with high moral and socially conscious. My parents taught me to be honest with everything and create value that makes the world a better place. I know many young people only think about making money and nothing else and that is why they have difficulty in their lives. They often switch jobs to get a little more money. They jump from job to job without learning anything well enough. After few years, they have high salary but no skills then eventually they worry about losing job. I believe that by working hard and constantly learning new things, I can make myself more valuable to the company that I work for. I always have this attitude when I was a developer and I still feel exactly the same today.
I feel very proud to call myself a project manager. The fact is I am not perfect because I am still learning but at least the last three software projects that I managed were delivered to customer on time, within cost and without any problem. Many developers want to work for me and my team is growing from twenty to fifty people. My next project is challenging but that will not stop me from continuing my learning and come up with good results. My last advice: All of you have selected software as a field to study and this is a field with wonderful opportunities. All of you have a career that will last many years in the future. Developing career is a long journey so keep on learning, keep a positive attitude and be humble then you will do well.”
Original source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1641
Project manager in Agile environment
Today Agile methodologies such as Extreme Programming (XP), Scrum,
Crystal, etc., are becoming more popular because the industry demands
that software development be done quickly and be responsive to change.
To compete in the global economy, software companies must move fast to
provide solutions to their customers.
Agile approaches of incremental build can deliver software faster than traditional plan-driven approach that follow a sequence order of life-cycle phases. This shift in approach also changes the traditional project management from planning and controlling to facilitating and collaborating. The Agile approach is depending mostly on the skills of the project team that is self-organizing to develop software without the command of a manager. This approach also leads to a shift in the organization structure and the skills of people who work there. For an established company with highly skills people, it is easy to adopt Agile but for a lesser matured company without a skilled workforce, the switch could be a disaster and that is why so many Agile project failed.
With Agile there is no role for project manager. This makes project managers confused whether they are needed or not. They must understand that their new role is to guide the team in responding to change as the team must make decisions instead of being told what to do. It also means more individual responsibility for team members, and more facilitation skills required for the project manager. The most popular Agile method is Scrum has two key individual roles that a project manager could do: Product Owner is the person who works closely with customers to decide what will be built and in which order. The Product Owner defines the feature of the product, chooses when the software will be released and adjusts features and priority as needed. The Scrum Master is the person who works closely with the team to ensure that the team is working together and productive. The Scrum Master facilitates team activities and enables cooperation across all roles and functions, removes barriers from external interferences, ensures that the process is followed such as the daily scrums, sprint reviews, and sprint planning.
Most traditional project managers are uncomfortable with these roles when transition to Agile but eventually many recognize that it does not matter what role they do, it is their responsibility to build a project team that can deliver quality product at a faster time. Of course, not everyone is willing to make this shift but for those who are willing, they will find both the process and the new skills they have learned to be rewarding and well worth the effort involved.
Agile approaches of incremental build can deliver software faster than traditional plan-driven approach that follow a sequence order of life-cycle phases. This shift in approach also changes the traditional project management from planning and controlling to facilitating and collaborating. The Agile approach is depending mostly on the skills of the project team that is self-organizing to develop software without the command of a manager. This approach also leads to a shift in the organization structure and the skills of people who work there. For an established company with highly skills people, it is easy to adopt Agile but for a lesser matured company without a skilled workforce, the switch could be a disaster and that is why so many Agile project failed.
With Agile there is no role for project manager. This makes project managers confused whether they are needed or not. They must understand that their new role is to guide the team in responding to change as the team must make decisions instead of being told what to do. It also means more individual responsibility for team members, and more facilitation skills required for the project manager. The most popular Agile method is Scrum has two key individual roles that a project manager could do: Product Owner is the person who works closely with customers to decide what will be built and in which order. The Product Owner defines the feature of the product, chooses when the software will be released and adjusts features and priority as needed. The Scrum Master is the person who works closely with the team to ensure that the team is working together and productive. The Scrum Master facilitates team activities and enables cooperation across all roles and functions, removes barriers from external interferences, ensures that the process is followed such as the daily scrums, sprint reviews, and sprint planning.
Most traditional project managers are uncomfortable with these roles when transition to Agile but eventually many recognize that it does not matter what role they do, it is their responsibility to build a project team that can deliver quality product at a faster time. Of course, not everyone is willing to make this shift but for those who are willing, they will find both the process and the new skills they have learned to be rewarding and well worth the effort involved.
Prof John Vu
Carnegie Mellon University
Original source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1539
Original source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1539
Saturday, September 1, 2012
Important factor for successful software project
Most successful software projects have two important factors: A good
software project manager and a highly skilled team in the domain in
which they are working. Basically, they are all about people and their
skills. Throughout my 40 years in software industry, I never encountered
a software project that failed because of technical issues but I have
seen many failures due to the “people issues” and this is one area that
the academic people did not know well. Most schools only focus on
technical issues but never prepare students to deal with the “People
issues”.
The idea that technical people only work with computers is completely
wrong. Many students think as long as they can code, they can do good
jobs that is wrong too. As soon as students enter the industry, they
will find that they will spend half of the time talking with other
people: obtain requirements from users, discuss the designs, review how
to integrate, debate on who would implement which function, analyze
which module would do what thing, and who would manage the interfaces
etc. They will learn that people have feelings and how they interact
with them will determine how they can make the project successful or
not. Everybody wants to be treated with respect, with courtesy and if
they understand that how they want to be treated then they should treat
others exactly the same. Eventually, they will learn that when people
work so hard without rest, they will create defects. When people are too
stressful, they will not think clearly and will make more mistakes.
When people feel uncomfortable they will easily get angry and if they
quit before project ends, the project will not meet the schedule.
Highly skilled people can overcome technical issues and make projects
success but they can NOT overcome bad management. Bad management
destroys everything. If managers underestimate the schedule, people will
NOT have enough time to do good works and quality will suffer. If
managers do NOT know how to manage people, the project team will have
conflicts with each other and project will fail. If managers do not
treat people fairly, the team will NOT work together well and arguments
among team members will happen….etc. My question is how many project
managers are trained in people management? How many project training
have focused on “People issues”? How many university’s programs have
courses in “People skills” or “soft skills”? If the school does not
teach you then you must find another way to learn more about these
skills.
Good project managers recognize the talent of their team and understand
that the success of the project is depending on their people’s efforts.
They know about project risks and how to mitigate them. Every software
project has risks but bad managers do NOT know them or know how to
prevent them. Because risks can occur anywhere and anytime, bad managers
often panic then blame their people rather than understand the state of
their projects. When people get treated unfairly, they get angry and
productivity will decrease.
Successful companies understand the people issue so they are very
careful in their hiring and only select people who can succeed in their
work environment. During job interviews, they will focus more on
teamwork questions and people skills than technical questions. They
understand that most graduated students have a good technical education
foundation so they do not ask about technical question. They know that,
if needed people can be retrained in technical. But they would be
careful with the personality, the attitude, the behavior because these
characteristics are difficult to change. Most successful companies do
invest in trainings, not just technical but also teamwork and “people
skills”. People in these companies understand that their job is not just
to deliver products but also to continually build capacity and work
together to achieve a common goal: Make the company more successful.
Every company need people who understand their jobs and know how to
apply their skills to build the software product. Every company needs
knowledgeable managers, people who understand how to manage both
projects and people, and who know enough about the business to make good
decisions.
By Prof John Vu
Orignal source :http://johnvublog.com/?p=72
Orignal source :http://johnvublog.com/?p=72
Difference between Software Project Management and Project Management
Few years ago when I taught software project management in Asian, I
found that there was confusion between “project management” and
“software project management”. Some universities used “Project
Management” books which were written for construction industry and other
industries but not software. For example, when they estimated efforts,
many began with 5% in conceptual and initiating phase, 10% in architect
and design phase, 75% in implementation phase, and then 10% on
maintenance. This is correct for construction industry. You do not need a
lot of people when working with owner to understand requirement needs.
Construction planning is mostly logistic and administration works. You
do not need a lot of people during architecture and design phases. The
architect designs the construction with a small team and when the
architecture plan is complete, it never changes. The major efforts
happen during construction phase when you need a lot of workers to build
the house. There will be some small efforts in the maintenance phase
(Painting and cosmetic decoration).
In software project, the most important phases are the first two.
Planning is critical and architect and design are essential. Since
software requirements often change, often late in the project; team
members must involve early to understand the business needs, analyze and
verify requirements to reduce the risk of requirements change. The
effort needed should be at least 20% in requirements phase, 20% in
planning phase, and 20% in architect and design phase. By having at
least 60% of team members involve in the project early, the team can
work with customers to collect requirements then breakdowns requirements
into smaller components where they can estimate more accurately.
Knowing the effort and time required to implement, they can plan the
project accordingly. The team organizes these components according to
architecture so in the end they all fit correctly. Only when these works
are done the team could design each component in more detail. By doing
most of the work earlier and make sure that all requirements are
accounted for; construction and testing would be easier. Software
project does not fail because developers cannot code; it often fails
because of bad requirements, bad planning, and bad project management.
Because of the confusion about “project management” and “software
project management”, some managers do not pay enough attention to the
early phases of software development resulting in many failure. In some
countries, software project management is not taught in undergraduate
program so students do not understand the concept and the software
project management life cycle. Most project management class is taught
in business school where students do not have knowledge of software
development. Without proper knowledge of software, without proper
software project training, many managers follow the common method of
“Code & Fix”. This method ignores requirements and design in favor
of a simple way to code first then fixing later. Project planning is
done by the project manager without the participation of team members.
Without proper knowledge of software, project estimate is based on the
schedule given by customer even customer really do not know how long
would take to complete the project. The project plan is based on a
budget given by manager without proper estimation. When it is approved,
it never been updated even requirements have changed. The team spends
most efforts on coding and fixing. The more they fix the more defects
they add so they have to fix it again. The cycle of code and fix
continues until the end. As a result, software project is costly, does
not meet schedule, and often has poor quality. Unfortunately, this
method is still being used in many places.
Some students asked me: “Why software differs from non-software project?
It is simple, software project deals with “intellectual work” when the
other deals with “physical work”. You can look at a physical work like
the construction of a house and know that how much it has been
completed. For example, 10% or 50% but it is difficult to do that with a
product which is still in the mind of developers. A good construction
manager know how long it will take to build a house, he can calculate
the size, the materials, and the labor efforts. It is difficult to
calculate the size and effort of a software project, especially during
early phases. That is why it needs a different approach and method to
manage software project.
I often ask students: “Can a non-software person (e.g., students from
business school) manage a software project? I have written about this
topic several times in my blog. I often use it as a topic for discussion
in my software project management class and it always create
interesting discussions among students.
My question to you: What are you doing on your software projects? I am
sure that you do not plan to fail, but if you have failed before,
perhaps it is time for you to learn more about software project
management or take a professional training course on this topic.
By Prof John Vu
Orignal source : http://johnvublog.com/?p=241
Orignal source : http://johnvublog.com/?p=241
Talking with customers
There is a common belief among software
developers that they must code as soon as possible since there is not
enough time for other activities. That is why many start to write code
as soon as they receive the requirements specification without spending
time to understand the customers’ needs. No one would ask customers
about their expectation or their needs. Most developers ignore the
architecture phase; spend little time in design, just to draw some
diagrams such as data flow diagram than jump into coding. If they do not
understand something, they would guess on what is needed and hurry to
get the project done to meet the schedule.
The result is often a software product that does not work as expect and they have to re-work to get what customers’ wants. This situation costs the company time, efforts and a lot of money. Today few colleges teach requirements engineering course, and even if they do, few developers would follow it. The reason among developers is talking with customers takes time and they do not have time. One developer told me: “It is difficult to understand what customers want as they change their mind often”. A project manager explained: “We cannot talk to customers; they would demand more things and waste our time.” When I asked: “What happen if the requirements specification is not clear? How do you know what to do if you do not want to ask? The common answer is: “We just guess what they want. If we are good at guessing, we will be fine but if not then we have to fix it later.”
Of course, most of the time they will produce something that customers do not want and that means more re-work, more costs to the company. I can understand why developers are reluctant to talk to customers; most are not trained and do not know what to ask so they think customers will ask for more and never be satisfied. But I cannot understand why managers do not talk to customers if the project continues to have high re-work rate? Until we establish a good dialogue between developers and customers, software development is just guesswork and costly projects.
There is an urgent need to teach requirements engineering course in the undergraduate program so students can learn how to discuss requirements with customers, determine their needs, set priorities and reduce the issue of re-work. Students should learn incremental releases that add functionality over time. Students should learn to talk with customers by asking questions about functionality and how customers will use their product. Once developers start talking to customers, they will learn many things about how the customers do their work and what they really need. Customers can help explain and clarify functionality written in the specification etc. When both sides engage in discussion about how long it takes to develop a project, they can exchange ideas, develop better solutions and agree on a better schedule for the project.
----------------------------------------
Prof. Vu
Carnegie Mellon University
The result is often a software product that does not work as expect and they have to re-work to get what customers’ wants. This situation costs the company time, efforts and a lot of money. Today few colleges teach requirements engineering course, and even if they do, few developers would follow it. The reason among developers is talking with customers takes time and they do not have time. One developer told me: “It is difficult to understand what customers want as they change their mind often”. A project manager explained: “We cannot talk to customers; they would demand more things and waste our time.” When I asked: “What happen if the requirements specification is not clear? How do you know what to do if you do not want to ask? The common answer is: “We just guess what they want. If we are good at guessing, we will be fine but if not then we have to fix it later.”
Of course, most of the time they will produce something that customers do not want and that means more re-work, more costs to the company. I can understand why developers are reluctant to talk to customers; most are not trained and do not know what to ask so they think customers will ask for more and never be satisfied. But I cannot understand why managers do not talk to customers if the project continues to have high re-work rate? Until we establish a good dialogue between developers and customers, software development is just guesswork and costly projects.
There is an urgent need to teach requirements engineering course in the undergraduate program so students can learn how to discuss requirements with customers, determine their needs, set priorities and reduce the issue of re-work. Students should learn incremental releases that add functionality over time. Students should learn to talk with customers by asking questions about functionality and how customers will use their product. Once developers start talking to customers, they will learn many things about how the customers do their work and what they really need. Customers can help explain and clarify functionality written in the specification etc. When both sides engage in discussion about how long it takes to develop a project, they can exchange ideas, develop better solutions and agree on a better schedule for the project.
----------------------------------------
Prof. Vu
Carnegie Mellon University
original source : http://www.segvn.org/forum/mvnforum/viewthread_thread,1499
Subscribe to:
Posts (Atom)