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.
