Copy
Posted on May 5, 2018 in Computers
Secrets of successful project management
Tip #1: define project success criteria. At the beginning of
the project, make sure the Stakeholders share a common understanding of how
they will determine whether this project is Successful. Tip #2: identify
project drivers, constraints, and degrees of freedom. Every project needs to Balance
its functionality, staffing, budget, schedule, and quality objectives. Define each
of these Five project dimensions as either a constraint within which you must
operate, a driver aligned Tip #3: define product release criteria. Early in the
project, decide what criteria will determine Whether or not the product is
ready for release. You might base release criteria on the number of High-priority
defects still open, performance measurements, specific functionality being
fully Operational, or other indicators that the project has met its goals. Tip #4:
negotiate commitments. Despite pressure to promise the impossible, never make a
Commitment you know you can’t keep. Engage in good-faith negotiations with
customers and Managers about what is realistically achievable. Tip #5: write a
plan.The hard part is actually Doing the planning—thinking, negotiating,
balancing, talking, asking, and listening. The time You spend analyzing what it
will take to solve the problem will reduce the number of surprises You have to
cope with later in the project.Tip #6: decompose tasks to inch-pebble
granularity. Inch-pebbles are miniature milestones.Tip #7: develop planning
worksheets for common large tasks. If your team frequently Undertakes certain
common tasks, such as implementing a new object class, develop activity Checklists
and planning worksheets for these tasks. Tip #8: plan to do rework after a
quality control activity. Almost all quality control activities, Such as
testing and technical reviews, find defects or other improvement opportunities Tip
#9: plan time for process improvement. Your team members are already swamped
with their Current project assignments, but if you want the group to rise to a
higher plane of software Engineering capability, you’ll have to invest some
time in process improvement. Tip #10:
manage project risks. If you don’t identify and control risks ,they will
control you. Spend some time during project planning to brainstorm possible
risk factors, evaluate their Potential threat, and decide how you can mitigate
or prevent them. Tip #11: estimate based on effort, not calendar time. People generally
provide estimates in units Of calendar time, but i prefer to estimate the
amount of effort (in labor-hours) associated with a Task, then translate the
effort into a calendar-time estimate. Tip #12: don’t schedule people for more
than 80%of their time. Tracking the average weekly Hours that your team members
actually spend working on their project assignments is a real eyeopener. The task-switching
overhead associated with the many activities we are all asked to do Reduces our
effectiveness significantly. Tip #13: build training time into the schedule. Determine
how much time your team members Typically spend on training activities
annually, and subtract that from the time available for them To be assigned to
project tasks.Tip #14: record estimates and how you derived them. When you
prepare estimates for your Work, write down those estimates and document how
you arrived at each of them.Tip #15: use estimation tools. Many commercial
tools are available to help you estimate entire Projects. With their large
databases of actual project experience, these tools can give you a Spectrum of
possible schedule and staff allocation options. Tip #16: respect the learning
curve. If you’re trying new processes, tools, or technologies for the First time
on this project, recognize that you will pay a price in terms of a short-term
productivity Loss.Tip #17: plan contingency buffers. Things never go precisely
as you plan on a project, so your Budget and schedule should include some
contingency buffers at the end of major phases to Accommodate the unforeseen. Tip
#18: record actuals and estimates. If you don’t record the actual effort or
time spent on each Task and compare them to your estimates, you’ll never
improve your estimating approach. Your Estimates will forever remain guesses. Tip
#19: count tasks as complete only when they’re 100% complete. One benefit of
using inchpebbles for task planning is that you can classify each small task as
either done or not done, Which is more realistic than trying to estimate what
percent of a large task is complete at anyTime. Don’t let people “round
up” their task completion status; use explicit criteria to tell whether A step
truly is completed. Tip #20: track project status openly and honestly. Create a
climate in which team members feel Safe reporting project status accurately. These
tips won’t guarantee success, but they will help you get a solid handle on your
project and Ensure that you’re doing all you can to make it succeed in a crazy
world.
DEFINITION- INTEGRATION OF PROCESSE : A business process or
business method is a collection of interrelated tasks, which solve particular
issue. There are three types of business processes: Management processes, the
processes that govern the operation of a system. Typical management processes
include “Corporate Governance”
and “Strategic Management”. Operational processes, processes that
constitute the core business and create the primary value stream. Typical
operational processes are Purchasing, Manufacturing, Marketing, and Sales. Supporting
processes, which support the core processes. Examples include Accounting, Recruitment,
IT-support. A business process can be decomposed into several sub-processes,
which have their own attributes, but also contribute to achieving the goal of
the super-process. The analysis of business processes typically includes the
mapping of processes and sub-processes down to activity level. In the early
1990s, US corporations, and subsequently companies all over the world, started
to adopt the concept of reengineering in an attempt to re-achieve the
competitiveness that they had lost during the previous decade. A key
characteristic of Business Process Reengineering (BPR) is the focus on business
processes. Davenport defines a (business) process as ”a structured, measured
set of activities designed to produce a specific output for a particular customer
or market. It implies a strong emphasis on how work is done within an
organization, in contrast to a product focus’s emphasis on what. A process is
thus a specific ordering of work activities across time and space, with a
beginning and an end, and clearly defined inputs and outputs: a structure for
action. … Taking a process approach implies adopting the customer’s point of
view. Processes are the structure by which an organization does what is
necessary to produce value for its customers.” This definition contains certain
characteristics a process must possess. These characteristics are achieved by a
focus on the business logic of the process (how work is done), instead of
taking a product perspective (what is done). Following Davenport’s definition
of a process we can conclude that a process must have clearly defined boundaries,
input and output, that it consists of smaller parts, activities, which are
ordered in time and space, that there must be a receiver of the process
outcome- a customer – and that the transformation taking place within the
process must add customer value. Hammer & Champy’s definition can be
considered as a subset of Davenport’s. They define a process as ”a collection
of activities that takes one or more kinds of input and creates an output that
is of value to the customer.” As we can note, Hammer & Champy have a more
transformation oriented perception, and put less emphasis on the structural
component–process boundaries and the order of activities in time and space. Rummler
& Brache use a definition that clearly encompasses a focus on the
organization’s external customers, when stating that ”a business process is a
series of steps designed to produce a product or service. Most processes are
cross-functional, spanning the ‘white space’ between the boxes on the
organization chart. Some processes result in a product or service that is
received by an organization’s external customer. We call these primary
processes. Other processes produce products that are invisible to the external
customer but essential to the effective management of the business. We call
these support processes.” The above definition distinguishes two types of
processes, primary and support processes, depending on whether a process is
directly involved in the creation of customer value, or concerned with the
organization’s internal activities. In this sense, Rummler and Brache’s definition
follows Porter’s value chain model, which also builds on a division of primary
and secondary activities. According to Rummler and Brache, a typical
characteristic of a successful process-based organization is the absence of
secondary activities in the primary value flow that is created in the customer
oriented primary processes. The characteristic of processes as spanning the
white space on the organization chart indicates that processes are embedded in
some form of organizational structure. Also, a process can be cross-functional,
i.e. it ranges over several business functions. Finally, let us consider the
process definition of Johansson et al. They define a process as ”a set of
linked activities that take an input and transform it to create an output.
Ideally, the transformation that occurs in the process should add value to the
input and create an output that is more useful and effective to the recipient
either upstream or downstream.” This definition also emphasizes the
constitution of links between activities and the transformation that takes
place within the process. Johansson et.al. also include the upstream part of
the value chain as a possible recipient of the process output. Summarizing the
four definitions above, we can compile the following list of characteristics
for a business process. Definability: It must have clearly defined boundaries,
input and output. Order: It must consist of activities that are ordered
according to their position in time and space. Customer: There must be a
recipient of the process’ outcome, a customer. Value-adding: The transformation
taking place within the process must add value to the recipient, either
upstream or downstream. Embeddedness: A process can not exist in itself, it
must be embedded in an organizational structure. Cross-functionality: A process
regularly can, but not necessarily must, span several functions. Frequently, a
process owner, i.e. a person being responsible for the performance and
continuous improvement of the process, is also considered as a prerequisite.