This page is for the work on Chapter 2: Initiating a Software Project
Owners of this page, please introduce yourself:
Name/ID
Name a hobby or
Something that you like to do:
Say something about your
experience with software
What would you like
to learn from this course?
How would you like
to learn from this course?
Fekri- 102-25-156
Watching Movie
Software will be a big part of human life, I mean we can be compare it with basic needs of human.
I want to learn, how to manage a software development project
By course text book with the help of some real life example and some practical project work.
Enayet/102-25-166
Task 1: Summarise the chapter below in terms of bullets: (10 marks)
Task 2: Explain the bullets in terms of the Grameen Bank Form 15 system. (10 marks)
Both Task1 and Task2 have answered together.
Chapter -2. Initiating a software project
# Determining the project’s actual goal Projects, big and small, have to be initiated. All initiation really means is that everyone acknowledges that the project has a purpose (and that everyone agrees on what that purpose is): to solve a problem, to grasp an opportunity, or to meet demand for a new piece of software. Fundamental purpose, at this point in the project life cycle, is to understand why the project is being initiated. But another crucial element to successful project management is to be in tune with the structure of your organization. Talking to the stakeholders when a project is being initiated, we want to capture as much information as possible about the project goals. Example: We can consider Grameen Bank as an example. Grameen Bank work with huge data. There were near about 600 branches all over the country. Branches were facing problems to managing data and providing reports. It has taken more time gather all reports to head office. Considering these issues Grameen Bank setup their Goals. # Managing various organizational bodies. Discussing high-level stuff with the executives. The executives want to know why any project is occurring because they want to confirm that the project aligns with their vision. If project doesn’t align with the company’s vision, kill it before someone else does. Questions need to ask executives, assuming you’ll be interacting with this crowd: What are the factors for project success? What’s your vision for the project result? What’s more important, time or budget? What risks do you anticipate for this project’s success? Playing nice with functional management. Who comprise functional works. Who are actually responsible for middle management. Their purpose is to carry out the vision of the executives. It’s at this level of the organization that tactics, strategy, and delivery of purpose to the employees take place. The functional managers must support the vision the executives have in the decisions they make. At this layer of the model, the functional managers need to understand the what of project management. The what centers on what the project will accomplish. Example:To implement software in Grameen Bank. We have to manage all governing bodies of Grameen Bank including Professor Dr. Unus. # Analyzing the project’s feasibility Feasibility plays an important role software development. Feasibility studies can answer questions, discover scenarios and unearth possibilities long before the project work begins. Some reasons to consider conducting a feasibility study are that these studies _ can save time and money. Some project managers consider the time and initial capital invested in a feasibility study a waste. They are wrong. When consider the amount of time and money needed to take a project from concept to completion, and the high likelihood of project failure, spending the time and money at the front end can protect larger amounts of time and capital in the long run. Feasibility studies just make good financial sense. _ serve as a research paper. It’s a factual exploration of the project’s likelihood for success. _ cheerlead the project manager’s point of view. For that matter, it’s neutral all the way around and shouldn’t promote anyone’s point of view. _ present alternate ideas. Your focus is on the merits and pitfalls of the project as it’s been articulated at this point. You shouldn’t be tweaking the ideas. __ Offer advice on the project’s initiation. A feasibility study just presents the facts; it doesn’t make a recommendation for the project to be launched or squelched. Projects may get selected in one of two ways: _ Constrained optimization: This is a complex approach that considers multiple variables, factors, and likelihood of project success. Selection committees use dynamic algorithms and linear and nonlinear programming to choose their projects. Doesn’t that sound like fun? _ Benefit comparison methods: Most organizations use this approach. Benefit comparison methods use accessible formulas, comparison models, and systems to choose which projects should be launched and which should not. Because these are the most common, we focus on giving details on several models. Say you have a proposed project. The project manager, really want company’s project selection committee to choose project Example:Project feasibility ensures the project base. Grameen Bank provide huge time and effort of there project feasibility purpose. # Reaching Project Consensus Project consensus is very important in the respect of our country. Sometimes project initiating meetings are opportunities for stakeholders to shoehorn their own pet agendas, wish lists, and one-upmanship into project. The trouble, besides being a real pain, is that it’s tough to discern what’s central to project. Understanding the project purpose during initiation is essential to guiding project consensus. Determining all the bits that go into the project scope comes later in the project. Right now, during the initiation processes, your goal is to get the majority of the stakeholders on the same page. To reach project consensus, your goal is to find common ground, and then to address ancillary requests that don’t infringe, change, or drive out the original project purpose. Example: According to form 15 after analyzing the project requirements and feasibility of Grameen Phone we must ensure the Project Consensus. # Unify the best work plan for the project Officially planning the project work. But as a rule, the earlier you know these details the better off the project will be. A project charter accomplishes the following: _ It identifies the project manager in writing. _ It identifies the project sponsor in writing. _ It authorizes the project manager to spend organizational resources on the project. _ It describes the product. That’s right; the description you worked so hard to create goes in the project charter. _ It specifically identifies the business need that the project was undertaken to address. If you have a business case, you can pull information from there. A charter can’t solve all your power struggles, negotiations, and other miseries — It’s not a panacea. But a charter does, more than anything else, authorize the project. Contracts, purchase orders, statements of work, and even work orders can be considered charters of sorts. See Chapter 12 for more information about contracts, vendors, and procurement. Planning the project. The second process group, the planning process, determines how the project will move forward after the project feasibility, description, and charter are complete. The planning process group gets the project rolling in a big way Example: Grameen Bank observed different work plan of the project but finally choose one which is the best matched with the project. # Identifying probable problems of the project here are many reasons a project will fail to deliver as expected, such as being late or over-budget. Project failure is such a problem that the project manager must actively manage that project risk. This should be done as part of the project planning process and subsequently through project active risk management. The project problem checklist is a simple planning tool to help the project manager identify project risks early and take action to avoid or reduce the chance of the risk becoming a problem. A simple categorisation of potential problems is: people, process and technology, with people often being the area with the most significant potential for causing project problems. Use the following checklist as a prompt for project planning. Potential People Problems
Wrong resource (lack of training, experience or expertise) identified for task
Resource unavailable when needed
Project is under-resourced or lacks specific needed resource
Project team working relationship generally or in specific cases is not effective
Poor project team working or communication with third party suppliers
Project team does not have access to expertise and external support
Decision-making processes and authority is not clear for project team, project board or stakeholders
People are not empowered to make appropriate decisions or do not have the personal authority to do so
Wrong stakeholders or specific stakeholders identified
Unclear communication with stakeholders
Ineffective engagement with stakeholders
Passive resistance by stakeholders who do not see the benefits of the project or do not support it
Project structure is unclear or with undefined lines of communication, interaction and decision-making
Unclear or undefined process for escalation of project issues (scope, financial, resource...)
Prioritization for people is unclear with potentially competing priorities
Resource conflicts
Potential Process Problems
Project methodology or approach is not clear or well-defined
Project control mechanisms (change, documentation, configuration....) are not selected or inappropriate
Processes defined for escalation, especially with third party suppliers
Unclear project reporting process [to whom by who, what, when]
Clear process for contribution to project by external groups that contribute to project but may or may not be part of the project team (quality, compliance, infrastructure, network...)
Relationship of project deliverables with organization’s quality management system or service management
Process for managing paper or electronic documentation and approval
Access to information or related system, especially for new project team members
Training processes for staff to comply with procedures or to obtain foundation level of knowledge for project tasks
Potential Technology Problems
Just released technology that may suffer from teething problems
Technology that needs to integrate with other technology and that has not been proven yet
Technology performance, availability, capacity or scalability is less than required
Technology resilience or redundancy is less than needed (ability to continue after a fault)
Technology does not exist yet i.e. potentially will be late, is new and consequently untried
Example: According toGrameen Bank there could be several problems. There could be training problems, implementation and data migration problem, power failure problems.
Owners of this page, please introduce yourself:
Something that you like to do:
experience with software
to learn from this course?
to learn from this course?
Task 1: Summarise the chapter below in terms of bullets: (10 marks)
Task 2: Explain the bullets in terms of the Grameen Bank Form 15 system. (10 marks)
Both Task1 and Task2 have answered together.
Chapter -2. Initiating a software project
# Determining the project’s actual goal
Projects, big and small, have to be initiated. All initiation really means is that everyone acknowledges that the project has a purpose (and that everyone agrees on what that purpose is): to solve a problem, to grasp an opportunity, or to meet demand for a new piece of software. Fundamental purpose, at this point in the project life cycle, is to understand why the project is being initiated. But another crucial element to successful
project management is to be in tune with the structure of your organization. Talking to the stakeholders when a project is being initiated, we want to capture as much information as possible about the project goals.
Example: We can consider Grameen Bank as an example. Grameen Bank work with huge data. There were near about 600 branches all over the country. Branches were facing problems to managing data and providing reports. It has taken more time gather all reports to head office. Considering these issues Grameen Bank setup their Goals.
# Managing various organizational bodies.
Discussing high-level stuff with the executives. The executives want to know why any project is occurring because they want to confirm that the project aligns with their vision. If project doesn’t align with the company’s vision, kill it before someone else does. Questions need to ask executives, assuming you’ll be interacting with
this crowd:
What are the factors for project success?
What’s your vision for the project result?
What’s more important, time or budget?
What risks do you anticipate for this project’s success?
Playing nice with functional management. Who comprise functional works. Who are actually responsible for middle management. Their purpose is to carry out the vision of the executives. It’s at this level of the organization that tactics, strategy, and delivery of purpose to the employees take place. The functional managers must support the vision the executives have in the decisions they make. At this layer of the model, the functional managers need to understand the what of project management. The what centers on what the project will accomplish.
Example: To implement software in Grameen Bank. We have to manage all governing bodies of Grameen Bank including Professor Dr. Unus.
# Analyzing the project’s feasibility
Feasibility plays an important role software development. Feasibility studies can answer questions, discover scenarios and unearth possibilities long before the project work begins. Some reasons to consider conducting a feasibility study are that these studies
_ can save time and money. Some project managers consider the time and initial capital invested in a feasibility study a waste. They are wrong.
When consider the amount of time and money needed to take a project from concept to completion, and the high likelihood of project failure, spending the time and money at the front end can protect larger amounts of time and capital in the long run. Feasibility studies just make good financial sense.
_ serve as a research paper. It’s a factual exploration of the project’s likelihood for success.
_ cheerlead the project manager’s point of view. For that matter, it’s neutral all the way around and shouldn’t promote anyone’s point of view.
_ present alternate ideas. Your focus is on the merits and pitfalls of the project as it’s been articulated at this point. You shouldn’t be tweaking the ideas.
__ Offer advice on the project’s initiation. A feasibility study just presents the facts; it doesn’t make a recommendation for the project to be launched or squelched.
Projects may get selected in one of two ways:
_ Constrained optimization: This is a complex approach that considers multiple variables, factors, and likelihood of project success. Selection committees use dynamic algorithms and linear and nonlinear programming to choose their projects. Doesn’t that sound like fun?
_ Benefit comparison methods: Most organizations use this approach. Benefit comparison methods use accessible formulas, comparison models, and systems to choose which projects should be launched and which should not. Because these are the most common, we focus on giving details on several models. Say you have a proposed project. The project manager, really want company’s project selection committee to choose project
Example: Project feasibility ensures the project base. Grameen Bank provide huge time and effort of there project feasibility purpose.
# Reaching Project Consensus
Project consensus is very important in the respect of our country. Sometimes project initiating meetings are opportunities for stakeholders to shoehorn their own pet agendas, wish lists, and one-upmanship into project. The trouble, besides being a real pain, is that it’s tough to discern what’s central to project.
Understanding the project purpose during initiation is essential to guiding project consensus. Determining all the bits that go into the project scope comes later in the project. Right now, during the initiation processes, your goal is to get the majority of the stakeholders on the same page. To reach project consensus, your goal is to find common ground, and then to address ancillary requests that don’t infringe, change, or drive out the original project purpose.
Example: According to form 15 after analyzing the project requirements and feasibility of Grameen Phone we must ensure the Project Consensus.
# Unify the best work plan for the project
Officially planning the project work. But as a rule, the earlier you know these details the better off the project will be.
A project charter accomplishes the following:
_ It identifies the project manager in writing.
_ It identifies the project sponsor in writing.
_ It authorizes the project manager to spend organizational resources on the project.
_ It describes the product. That’s right; the description you worked so hard to create goes in the project charter.
_ It specifically identifies the business need that the project was undertaken to address. If you have a business case, you can pull information from there. A charter can’t solve all your power struggles, negotiations, and other miseries
— It’s not a panacea. But a charter does, more than anything else, authorize the project. Contracts, purchase orders, statements of work, and even work orders can be considered charters of sorts. See Chapter 12 for more information about contracts, vendors, and procurement. Planning the project. The second process group, the planning process, determines how the project will move forward after the project feasibility, description, and charter are complete. The planning process group gets the project rolling in a big way
Example: Grameen Bank observed different work plan of the project but finally choose one which is the best matched with the project.
# Identifying probable problems of the project
here are many reasons a project will fail to deliver as expected, such as being late or over-budget. Project failure is such a problem that the project manager must actively manage that project risk. This should be done as part of the project planning process and subsequently through project active risk management.
The project problem checklist is a simple planning tool to help the project manager identify project risks early and take action to avoid or reduce the chance of the risk becoming a problem. A simple categorisation of potential problems is: people, process and technology, with people often being the area with the most significant potential for causing project problems. Use the following checklist as a prompt for project planning.
Potential People Problems
- Wrong resource (lack of training, experience or expertise) identified for task
- Resource unavailable when needed
- Project is under-resourced or lacks specific needed resource
- Project team working relationship generally or in specific cases is not effective
- Poor project team working or communication with third party suppliers
- Project team does not have access to expertise and external support
- Decision-making processes and authority is not clear for project team, project board or stakeholders
- People are not empowered to make appropriate decisions or do not have the personal authority to do so
- Wrong stakeholders or specific stakeholders identified
- Unclear communication with stakeholders
- Ineffective engagement with stakeholders
- Passive resistance by stakeholders who do not see the benefits of the project or do not support it
- Project structure is unclear or with undefined lines of communication, interaction and decision-making
- Unclear or undefined process for escalation of project issues (scope, financial, resource...)
- Prioritization for people is unclear with potentially competing priorities
- Resource conflicts
Potential Process Problems- Project methodology or approach is not clear or well-defined
- Project control mechanisms (change, documentation, configuration....) are not selected or inappropriate
- Processes defined for escalation, especially with third party suppliers
- Unclear project reporting process [to whom by who, what, when]
- Clear process for contribution to project by external groups that contribute to project but may or may not be part of the project team (quality, compliance, infrastructure, network...)
- Relationship of project deliverables with organization’s quality management system or service management
- Process for managing paper or electronic documentation and approval
- Access to information or related system, especially for new project team members
- Training processes for staff to comply with procedures or to obtain foundation level of knowledge for project tasks
Potential Technology Problems- Just released technology that may suffer from teething problems
- Technology that needs to integrate with other technology and that has not been proven yet
- Technology performance, availability, capacity or scalability is less than required
- Technology resilience or redundancy is less than needed (ability to continue after a fault)
- Technology does not exist yet i.e. potentially will be late, is new and consequently untried
Example: According to Grameen Bank there could be several problems. There could be training problems, implementation and data migration problem, power failure problems.