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.