If the creators of the product cannot agree on a direction of how the
project should move forward or what the software should even do and be
capable of, then the project is in danger before it ever leaves the planning
stages. The first method I could see using to get this issue resolved is to
get all interested parties in this, which in this case is first going to have
to have to be the two partners in the same room, to hash out all of the
details of what the software needs to be capable of and what features need
to be in use and spotlighted going forward. Another is to go over all the
details in a written manner like a mediator and use my own and the teams
expertise to reach a conclusion and a pitch of how the software should be
designed, tested and deployed. As far as methods to move forward, I do
believe someone else mentioned this already but the waterfall method would
be an effective tool in this as it would require each stage be done in
sequence before moving to the next. It is also risky in the fact that it
could suffer some hang-ups if there is an impasse between the parties again.
Another effecting method to use would be the adaptive, as it allows for
changes on the fly while going through all stages. Again though this could
be an issue if they decided to keep making changes back and forth which
would slow down the end result being deployed to the customer, in turn
losing their sales numbers and hurting the business. This project is already
risky due to the fact that the two partners cannot agree on what the end
goal should be. If they cannot agree, then how do I know what to do?
Also, if they can't agree then the company is on the trajectory to fail.
There are too many ideas that do not align, however some of the ideas
could be on the same page. The first method I would use is to interview
the two separately and kind of do a compare and contrast. This would help
me come up with a plan and present to both. This will take both of their
ideas and use the best ones that they came up with. Then, hope that will
get them on the same page. Another method I could use is, with their
permission, look through documents and things to get an idea of what they
need and come up with a plan from there. Hopefully this will answer what
they actually want and again get them on the same page. If project
stakeholders cannot agree on the requirements, the project's success may be
jeopardized. If there is no clear definition of what defines completion, the
project may be jeopardized. I would utilize two distinct ways to gather the
project's needs. The first step is to have a dialogue with the organization's
customers, employees, and owners. An in-depth interview may provide you
with helpful information and fresh views on critical parts of the project. I
would give more weight to comments from the floor personnel since they
would be utilizing the system on a daily basis and are the most acquainted
with the method as well as what works best for both the customers and
themselves. The next way I may use to get knowledge about needs is
observation. Keeping an eye on the Workflow as well as the day-to-day
operations will help you understand what the stakeholders want as well as
what features would be nice to have but aren't necessary. If you return to
the owners with your findings, they may be able to reach an agreement on
the objectives that the program should aim towards. If there are two partners
that are already could not agree, there are some risk factors to consider.
Firstly, the companies goals won't be aligned and thus causing delays in the
project. Another factor to add in to the first example, is if delays are
caused due to miscommunication, then that would drive costs up because that
would force other members of the different stages (planning, testing,
construction) to do more work. The first method I would use to gather
requirements, is to gather all the supporting parties and discuss all what is
needed and wanted for the company. There are two different methods we can
utilize for this, a predictive development model and an adaptive development
model. A predictive development model involves models like the waterfall to
have stages throughout the project and have deadlines. The downside to this
is it usually takes a lot longer for a larger project and could cause delays.
An adaptive development model enables the team to change the project's
goals if necessary during development. Having frequent meetings to discuss
any issues that have arise and to have that adaptive mindset to benefit the
company. In many ways, the project can be classified as a risky project.
The first example could be when the project involves many complexities and
engages emerging or new technologies within the business; then, the project
can be classified as risky. Another example could be if the project has a
high potential growth for unfavourable outcomes or a high chance of being
unsuccessful, then it can be considered that the project is to be at high
risk. In the case of writing sales software for a small sports equipment
supply store, both of these examples fit where the development of sales
software might go into risk with the high complexities and high chance of
unsuccessful and unfavourable outcomes .While gathering the requirements for
the potential project, many methods could be engaged in project management.
The first method that I would like to employ in the project is analysing
existing documents to gather requirements for the project. It is considered a
useful technique as it helps review the current documents and processes to
understand the current business, situation and system and provide better
solutions for future improvement. Another method that I would like to use in
the project is interviewing to gather requirements. This can help to get
various responses. Risky projects could seem sketchy with how they are
presented such as not having a clear goal or endgame for what they want
or not even having a clear showing of how they want to fund the project.
Another way it would be sketchy is to have an unrealistic timetable and
expectation for when the project would be done, setting goals for the project
without knowing or caring how the project should flow or the time and
effort it takes to complete it.Attempting to get as much information from the
stakeholders on what they really want would be tough as well if they aren’t
invested in the project. Gathering information would take a much longer time
to complete and could cause them to drop the project or attempt to get
someone else to do the job. Presenting the stakeholders with similar projects
to show them the actual costs and time needed to complete the project
would help show them what level of support the team would need to
complete the project. Two methods to gather information for this would be
first observing, checking out the company and what they do, what their
employees do and what they need for the project compared to what the
stakeholders think they need and showing them the different needs that the
company has. Combining this with document analysis would go along with
checking what they system needs to do and to present them with a proposed
system requirements with the functionalities that are needed based off use.
The first example of this project being classified as risky is that the partners
of the small sports equipment supply store don't seem to see eye to eye.
That can be troublesome for a developer because, you might be getting two
different directions that they want you to run in. I'll bunch in time and
budget into one category, because they are usually correlated. Having a tight
deadline and a small budget can definitely prove to be risky. One way I
would gather information about the requirements for this project is to look
outside of the box and see what other companies in the industry are using
and why. This can give me great insight and I'll be able to use this
information for the second way to gather information, which would be to
brainstorm with the partners. I can use the template of the software that
competitors are using to help bring them both in agreement. However, I
would not limit myself to only two methods. There are several practical
ways to gather as much information as I can to get a clear picture of the
task ahead. I would personally consider a project to be risky when there are
unclear requirements or when the project has a rushed date. The two models
I’ll be using for my examples is predictive development model and the
waterfall model. it comes to the predictive development model, general use is
if you are able to look at a business system, decompose it and quantitatively
(data collection) represent its internal state (feature selection), then
model/predict how that internal state changes based on time/other inputs. The
predictive model can be used to know what the specific time frame should
be. In the other hand Waterfall is the ultimate "happy path" of software
development. Everything works in specific stages. Every step is completed
before the next one can begin. So, when you gather up every requirement
you want to meet, then design everything about the program to meet the
customers’ requirements could change, or you find out that something in your
design didn't cover a requirement the way you want. Unfortunately, that’s
hard to do in waterfall, because you're supposed to be done with it already,
there's typically no bandwidth in the team to handle it, since everyone's
working on another step. There are many risks involved when two partners
don’t see eye to eye on what a specific software should do. One risk I
see in this situation are incomplete and unclear requirements. Two partners
with different views on how a product should function could provide different
requirements or leave out specific functions. Another risk that goes hand in
hand is the lack of a funding. One partner may see their requirements not
being met and may not provide the necessary budget to complete the project.
Two ways I would use to gather the requirements for this project is to look
at the current software and methods being used. This way I can determine
what the partner think about the current software that work well and what
part do not. Second, I would interview them separately to determine how they
see the new software should work. This can help find common ground for how
the new software should function. It may also highlight other factors that were
not considered originally that could help align the partners views. Methods I
would use to gather requirements for writing a sales software where the
two partners could not agree on what exactly the software should do:
1. I would do research on the current system and business. ww The first
thing I would do is understand the business mission statement to
understand the business goal and what is important to the business.
Next, I would research to see what sales software they are using. In
doing this I would look to understand the pros and cons of the
current system and why an upgrade is needed.
2. I would conduct an interview with both partners together. I would
start the interview off with verifying the business mission statement to
help align the two partners in what they want the new software to
be. I would then review the current system with them and understand
what they like, don’t like and why they want a new program. I
would ask each partner to take turns on what they want the new
software program using the Moscow method. This would help me
understand where the common ground is and build off that. In the
interview I would use the 5 Ws and the 1H.
Projects face risks of failure quite often. There are many reasons to classify
a project as risky. The two I will highlight are the lack of appropriate
funding and stakeholders not giving the project proper support. First, funding
a project can sometimes be extremely complicated. Even if a business
believes they have funded a project fully, there are many costs that can
creep up unexpectedly. One of the major ones are change orders. For
example, a company has several integrations, but left an obscure yet
important one out of the scope of work. Usually adding the integration as
a change order is not an issue, but most change orders come with an
additional cost. In addition to change orders, another situation that can
unexpectedly arise is the need for updated hardware or software. Perhaps
their current system runs on Windows 7, but the new build requires an
upgrade to Windows 10. Generally that would be an easy upgrade, but
sometimes a new computer terminal will also be needed to accommodate the
operating system upgrade. Since lack of proper funding can derail a project
It is always wise to set aside additional funding. If the money is not
spent during the initial stages of the project it can be used for annual
maintenance or desired upgrades. The next risk is the lack of proper project
support by stakeholders. Stakeholders hold a great deal of power when it
comes to the success of a project. A lot of stakeholders are informal
leaders and hold sway over others. If they choose not to support the
project, others will follow. this can impact every part of the project from
building to training to implementation. Each of those pieces need to be
appropriately supported in order to be successful.
The methods I would use to gather requirements would be interviewing
stakeholders and observation. Making sure all stakeholders have some
involvement in the project will go a long way to earning their support.
Each stakeholder should have a voice, since an administrator may have no
idea what a front line user needs and vice versa. In order to get a
balanced view each position should be interviewed. Observation is necessary
since seeing how someone does their job can capture information that was
overlooked in interviews. Sometimes a user may do things out of habit or
muscle memory and not realize there is a functional requirement behind it.
This is also a helpful way to verify the information received in the
interviews makes sense and clarify any gaps in the information. Software
engineering projects are driven by business needs. There are many different
risks that can arise in a software engineering project. The common risks
include project scope changes, technical challenges, schedule and budget
overruns. In this scenario, the scope of the project poses a risk to the
entire project because the partners are not in agreement of what the scope
of the project should be. With the undefined / fluctuate scope, the project
will take longer to complete thus increase in cost for the project will
occur.
To gather information for this retail store sale software, interviewing and
requirement workshops would be appropriate for this situation. Interviewing
stakeholders (store partners, store manager and sale associates) to gather
information about their needs and expectations for the software application.
This method is useful because the project team can obtain valuable insights
that can be used to build the features and functionality that are most
important to the store for the application. ww Requirement workshops would
bring the stakeholders together along with the project team to discuss and
identify the requirements for the software application and working toward a
detail information/scope of the project that would be aligned with the needs
of the store and its customers. I would have to say that project risk
management is a process of managing risks associated with projects. It
involves identifying, assessing, and mitigating risks. Some of the common
types of project risk are project scope change, budget change or resource
availability change. Risk management is an important part of project planning
and execution to ensure that risks are minimized as much as possible.
When it comes to scope change the stakeholders may have different ideas
comparing to what you have for the project. If you and the stakeholders
can’t come to an agreement, then the project that you plan to work with
would not be completed. Therefore, you need to be able to figure out
what to discuss and how you and the stakeholders can come to an
agreement. It’s much easier to defend decisions and keep scope in check
when you’ve documented and agreed upon project deliverables before work
begins says .Knowing what risks to watch out for and how you’ll address
them can go a long way in easing anxiety for everyone involved in the
project. Two ways that I would use to gather requirements are document
analysis and observation. Frequently overlooked, document analysis is another
highly effective technique for gathering requirements. One of the best ways
to understand what users truly need is to observe them performing their
daily tasks. By observing end users in the real context in which they
perform their tasks, you’ll gain a true understanding of what they are up
against and what improvements they need so they can perform better. You’ll
then be better able to specify a system that successfully reinvents users’
processes and grants them far greater productivity and usability, rather than
simply providing them an incremental improvement. Handling requirements is
another way of categorizing models. A Predictive Development model is an
advancement of thought on the needs before it is done. The design is
based on the requirements of the system and is used as a blueprint for
the code to be written. Sometimes it's hard to know what it needs and
the materials to build it. Moreover, if the developers aren't familiar with a
technique to use, it is incompatible with the program to work.An Adaptive
Development model is a way to change the goals of the project during
development if it is necessary. This will reevaluate the changes in the
design's direction when the outset is not relevant enough. An example of
this is watching a detective show. It has a detective trying to find the
killer, he/she has the necessary tools, and each time he/she finds a clue,
the direction becomes updated.
A Sashimi Development model also known as the SashimI Waterfall phase
is just like the Waterfall model but it can overlap the steps. There are
three types of prototypes; throwaway, evolutionary, and incremental type. A
throwaway is a study of the system being tossed out once it is gathered
and then the developer writes the code from the beginning based on that
system. An evolutionary prototype is a type that describes the application's
features. During the process, refinement of the features is established, new
additions are replaced, and the finished app is based off of those new
features. An incremental is creating a collection of other types from the
characteristics of their finished version, a combination of the applications. It
is easier for developers to work on individual pieces from separate
prototypes. Feature-Driven Development is both an iterative and incremental
model where large teams use risk, the value of customers, or the waste to
guide their development process at a higher level. The features listed in this
build are popularized and become added. It goes through five phases;
develop a model, build a feature list, plan by feature, design by feature,
and then build by feature. Two partners which are unaligned will derail the
project, disappoint the customer, and ruin their reputations. The partners
should be able to communicate and collaborate effectively. These risks can
be unavoidable when the two partners have different visions, levels of
experience, expertise, and technical skills. One of the partners will dominate
the other partner and will hinder collaboration because they will have a
different understanding of the system requirements, tasks, and processes.
Unaligned goals will be another risk for the project. Both partners should
have clear objectives for the project and the deliverables at the end of the
project.
One partner may have higher technical knowledge than the other partner. The
more experienced partner will lead in the development process, and this might
inhibit the learning experience of the other partner. To avoid these types of
risks, both partners should have similar levels of skills and experience so
they can collaborate effectively on the project.A lack of resources can cause
significant problems for the software project. Resources include the time,
budget, and resources that are required to complete the project. If one or
both partners lack the required resources to complete the project, they will
have to make difficult sacrifices in order to complete the project on
time.Two methods I'd use to gather requirements for this project would be
interviews or surveys. Interviews could be done with key stakeholders to get
the requirements from different perspectives. A survey could be sent to
customers to learn more about the requirements for this project. I would use
a combination of both methods to collect information for my software project.
I would also use workshops to gather more information from these key
stakeholders and customers. In this situation there are two partners that want
this sales software, but they are unable to agree on what it should do. That
in itself is a risk for the project. One of the biggest risks to software
development is the purpose and need not being well defined. Be able to
agree on what the program should do falls under the purpose and need
category and the stakeholder risk. With these partners not agreeing they won't
be able to execute the project wisely. They become stakeholders in the
project because they have the most interest in the project succeeding and
with them disagreeing it succeeding will become difficult. I would start by
doing stakeholder engagement because getting the partners to agree on what
the software should is important before any planning or development can be
started. Even, if it's just a very basic and simple idea to start with.This can
be achieved in many different ways by brainstorming, questionnaires, surveys,
or presentations of various ways that the software could work. Once we get
them to agree then when can start documenting requirements. The require are
important because they can define the various features that will be necessary,
how many users will it need to support at a given time, and even where
and how they want to store customer information. I would generally do more
than what is described here, but I think this is a good place to start. For
this weeks discussion topic of two small sports equipment store partners not
agreeing on what the proposed sales software should look like or do, I'd run
away from this project! Just kidding, but what a mess. I wonder how their
brick and mortar store is functioning, or not functioning. One partner must
be carrying the load to avoid conflict. Anyway, back to the question. One
reason this project if classified as a risky project would be by definition of
a Waterfall model having clear and well defined objectives. If the model
needs to complete one step before moving to the next step, they would
never get past the first step of gathering what the software should look like
and do. High level design will never happen if the two partners can not
give you a clear picture of what they want. In the real world would it be
possible to give them a example of past working software's to agree upon?
Another reason this would be a risky project would be the possible conflict
as the project continues or nears completion and the partners see an example
of their new sales software and not liking what they see.So, two methods I
would use to push this project along would be one on one, or face to face
interactions like brainstorming or group discussion. This would give all parties
some sence of urgency to get on the same page. One way a project would
be a risk is the stakeholders not agreeing on the requirements. Another way
the project would be put at risk is if there is not a definition of done. I
would use two ways to gather requirements for the project. The First would
be to interview the owners, the employees, and the customers. A good
interview can get you some good insights into what is needed to make the
project successful. I would put more stock in the feedback I got from the
floor employees as they are the one that will use the system day to day
and know how the workflow is and what works best for them and the
customers. The next requirement gathering technique I would use is the
observation. Watching the Workflow and day to day operations will help you
understand what the stake holders need and what would be a nice addition
but not necessary. Then going back to the owners and presenting your
findings may help them come to an agreement for what the software should
do. Part of the issue with the first risk is we all need to be on the
same page in order to know where the end goal is and how we even
achieve it. I would want to sit them down first over a couple of meetings
to make sure that we iron out what would be the result of the software.
Obviously, it's to make money but how will that be achieved? The second
issue would be making sure that once we iron out that plan idea of what
the partners want, getting their designers involved to help consider what will
need to be part of the over-user experience to make this work well for the
customers they would be targeting. If there is something we need to hire
outside help, what exactly would we need help with? By doing this I hope
to get both partners on the same page, get the information I would need
and then work with everyone to get this project done in a reasonable time!
.When I think of a risky project, I think more along the lines of an
unrealistic timeline and scope or the project lacks a skilled team. I would
not think the project would be brought to the table for discussion if the
requirements were still in the air or if there was not adequate funding. If
the stakeholders can’t decide on what is needed, how are the people doing
the work supposed to deliver? They need direction and to get paid.I think
document gathering is the same for a risky project and a not-risky project.
I think you would have to lay out the risks and probably give ideas on
where the risk can be mitigated. Maybe after getting all the ideas together,
you can nudge them in the right direction by saying a, b and c are doable
with your budget and ideas, but d, e, and f are not because of budget or
because they cannot clarify exactly what they are needing. This is a situation
where I think someone needs to think outside the box and probably read
between the lines to translate what is needed. When stakeholders do not
agree on the project requirements and the needs that they are trying to meet
with the software applications they are developing for the stakeholders, it is
a great indication that the project is at risk to fail. As a software engineer,
it is critically important that you align the stakeholders' view of the project
requirements and needs of the project. If project stakeholders disagree on the
problems being solved or what the future state solution will look like, the
project will not succeed. It is extremely important for stakeholders to be on
the same page and to have a shared vision of the goals, expectations, needs,
and requirements of a project. If not, the project will be at risk, and
stakeholder expectations will not be met. When this happens, stakeholders and
the project team become very frustrated, and the project does not progress
efficiently and effectively and is at risk to fail. It is important that the
project manager and project sponsors make sure that expectations, needs, and
requirements are aligned into one shared vision so that the project has a
better chance to succeed. Brainstorming is a great way to realign the partners
to develop creative approaches and ultimately decreasing the amount of risk
to the project. I think people underestimate the value of trust and
communication and often let the chips fall instead of putting egos and
differences aside to achieve our common goals. Another point to consider is
to teach them appropriate skills to help them resolve the issues. It is so
important to teach stakeholders and project team members appropriate skills to
complete their work. This week, I had to work closely with one of my
managers and his project team. He has a skills issue with some of his team
members that I helped him to address. Unfortunately, when team members
don't have the skills, they need to succeed at their jobs, they put their
projects and work at risk. In addition, I also worked with this manager on
his skills. As the manager of this team, he should have identified the issues
and rectified them without me having to be involved. I spent time providing
him with additional training so that he could address these issues, as the
team manager, if they arise again in the future. Organizations have always
been part of history in every area of life – from personal to community
and from philosophy to enterprise. Corporations have done with affiliates
across nations, companies, or within their meaning franchises for a range of
purposes, whether from a need to grow or a need to cut off prices. Yet,
in current years the development of alliances has enhanced, driven by the
advantages of probability sharing and supply pooling, expertise merging,
manufacturing deconstruction, and knowledge dispersion. Good development
executives will be capable to steer through their plans and provide their
deliverables on scheduled time. Industries often have additional than one
design going at some given moment in time. I can agree with you 100%
that the partners should communicate and collaborate. Part of collaborating and
communicating is how new projects can be developed. If there's no
communication, then the new project wouldn't be processed which can cause
a huge reputation for the company. Collaboration improves the way your team
works together, and problem solves. This leads to more innovation, efficient
processes, increased success, and improved communication. Through listening to
and learning from team members, you can help each other reach your goals.
Providing a defined line of communication throughout the organization so that
the team members know where to find the required information and how to
accomplish the tasks effectively. Setting the goals and rules are necessary to
keep employees on track and focused on their current goals. It will ensure
efficient collaboration in the workplace. I also agree that a lack of resource
can cause trouble. Resource management ensures resource managers have on
demand, real-time visibility into people and other resources so they can have
greater control over delivery says . When you execute resource management
properly, you can help your organization reduce costs, improve efficiencies,
and boost productivity.
