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. zz 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. zz 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.
