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