Posted by maria bodkin on Apr 29, 2016 in Uncategorized
If there are changes in the environment, then your business case and solution will become obsolete before you’ve actually finished the project. You may have to review your original requirements and goals at some point in the project to decide how to proceed. This may result in tremendously changing the scope of your project or canceling the project. This is probably the trickiest area resulting in project failure There are many more types of impacts as well and you can look to your industry to come up with typical examples. Health and Safety and environmental impact are two popular categories. However you categorise risks your team doesn’t have to restrict themselves to the list. Just because my table doesn’t address environmental risks doesn’t mean we shouldn’t consider the risk unexpected disposal costs as a result of the type of batteries e install into our computers we manufacture. n cases where the risk is considered unworthy of effort to manage it can be accepted. This may occur in instances where the risk is so unlikely to occur as to not warrant attention, or where the impact is insignificant in the content of the business and project’s environment. Whichever option you pick for your risks you should have a detailed action plan against the risk which includes Who is responsible for managing the risk What is going to be done to manage the risk When are the major work activities to manage the risk going to start and end How the risk will be managed as a result of this management plan – that is the planned outcomes of the risk management plan For risks that require major bodies of work to be managed appropriately you should consider raising a change request and revising the project management plan to include new or modified work packages including this new work. Historically, businesses have viewed risk as a necessary evil that should be minimized or mitigated whenever possible. In recent years, increased regulatory requirements have forced businesses to expend signifi cant resources to address risk, and shareholders in turn have begun to scrutinize whether businesses had the right controls in place. The increased demand for transparency around risk has not always been met or met in a timely manner, however—as evidenced by the fi nancial market crisis, where the poor quality of underlying assets signifi cantly impacted the value of investments. In the current global economic environment, identifying, managing, and exploiting risk across an organization has become increasingly important to the success and longevity of any business Organizations that vigorously interpret the results of their risk assessment process set a foundation for establishing an effective enterprise risk management (ERM) program and are better positioned to capitalize on opportunities as they arise. In the long run, this capability will help steer a business toward measurable, lasting success in today’s ever-changing business environment. Risk...
Read More »
Posted by maria bodkin on Nov 19, 2014 in blog
Why, you ask? Well there are lots of reasons and this blog’s aim is to educate businesses on the practical reasons as well as the strategic need to adopt HTML5. If you are an IT savvy person and know all about HTML5, then this blog is just a waste of your precious time. On the other hand, if you are a business owner this blog could be of great value to you. I’ll start with a primer for you non-techies. What is HTML5? HTML5 is the updated version of the code (computer language) used in creating websites. This updated version is browser-based. HTML5 it can make your website’s content much more interactive and accessible. Said differently, HTML5 is the next version of HTML web design language and it comes with numerous related advances in web technology. What is a Browser? A browser is a program with a graphical user interface/the presentation mode, for displaying website content. Google Chrome, Firefox, and Internet Explorer are the most widely used browsers today. From a business perspective, there are many valuable features. HTML5 is being designed to integrate multimedia, e.g., videos, images, graphics, to have app-like usability, to be mobile friendly and to enable dynamic content. HTML5 has been around for several years now, but it’s finally approaching the point where the standards are all agreed and finalized. It’s been about 3 years since web developers and designers were given the all clear to start using HTML5 on their websites and web-apps. The W3C has revised its Recommendation Plan for HTML 5.0 in the fourth quarter of 2014 and an HTML 5.1 for the fourth quarter of 2016. So, now is the time if you want to optimize the benefits and minimize the risks in adopting HTML5. At the end of 2016, in a new release, HTML5.1 will implement more features and those features that are considered unstable in HTML5 will be corrected. It is assumed that new releases of HTML5 will be introduced every 2 years according to W3C’s cycle trends. (W3C is the World Wide Web Consortium, the main international standards organization for the World Wide Web.) Features of HTML5 from a business perspective Browser Compatibility A browser is a program used to navigate the World Wide Web, e.g., Google Chrome, Internet Explorer. HTML5 is compatible with most or all browsers whereas we web developers have to account for each browser’s differences when we develop and especially test websites. There is a good possibility that your HTML4 site may loose support on certain browsers. But the developers of HTML5 are doing their best to ensure browsers can handle HTML4. Nonetheless when your potential customer visits your website and then your HTML5-competitor’s site chances are they’ll get frustrated and buy from your competitor. Because the competitors website will be richer in content, usability and visuals. And because of this your competitors will increase their market share, which will enable them to...
Read More »
Posted by maria bodkin on Nov 8, 2014 in blog
Non-Value added time and delays to the project result if dependencies are not managed I’ve often seen contractors and sub-contractors begin design and development for their piece of a project only to find they have to revisit both due to other dependent items that must be completed prior to the contractor’s design and development effort. Even if no technical dependencies are established, the testers cannot start testing until other pieces of the code are completed. This results in either unnecessary time spent (=$) by the contractor or added costs to the client, not to mention delays to the project. We Project Managers must be able to plan for and manage the dependencies among tasks in the network diagram when scheduling. A dependency is a link amongst a project’s activities or tasks. The greater the project complexity requires further dependency planning. There are four relationship types of project planning dependencies in three categories. The relationships between dependencies are Finish to Start, Finish to Finish, Start to Start and the least used one Start to Finish. In keeping with the spirit in this blog series, that is, minimizing project failure risks, a key tip in getting your projects in on time is learning how to break-down dependencies. Dependencies in a project happen when at least two tasks or activities depend on each other. The most common type of dependency is a “ Finish to Start” (F2S) dependency. This means the first task must finish before the second task can start. For example, if you’re building system feature, you cannot test the feature before it’s developed. The problem with dependencies is that they force a constraint on the project’s schedule. If you have two different tasks or activities that both take a day to complete, with the right resources you should be able to get both done in a day. But, if there is a F2S dependency on the activities, then your group of activities is forced to take two days. It’s for this reason that when I begin a project, given I have the optimum number of skilled resources (yeah…right!), I like to break the dependencies down as much as possible. There are a few tips at the end of this blog concerning the use of dependencies to minimize risk on a project. A clear understanding of the four network diagram relationships is necessary before we begin to offer strategies on managing those dependencies. That said, here’s a brief lesson on the four types of network diagram relationships (in order of frequency of use): 1. Finish to Start (FS) F2S = Task B can’t start before Task A is finished New system requirements must be completed before designing the new system 2. Finish to Finish (FF) F2F = B can’t finish before A is finished The design for order cancellation (B) cannot finish before the design of order entry (A) 3....
Read More »
Posted by maria bodkin on Jul 12, 2014 in blog
Having part-time resources on the project may be the riskiest issue In hindsight, this may be the riskiest issue even on straightforward projects. Nonetheless, in reality, part-time project members are quite common. This is when a team member has other work responsibilities, typically in the functional area of the project. These resources can dedicate only agreed time to your project. This in itself is not an issue. It is when the person does not report directly to you but also to a functional manager in their department that causes the project risk. Don’t get me wrong. I absolutely sympathize with part-time project team members. The problem is not the part-time team member, it’s the part-time assignment that increases project risk. The part-timer is trying to keep everyone happy and is constantly juggling the demands of both roles. As the project manager, you must work with both the functional manager and part-time team member to prevent added risk. An agreement can be instituted before the part-time team member begins its work. Written Agreement Forget about being uncomfortable with an agreement. If your culture allows for it, you might wish to get a commitment in writing from both the functional manager and part-time team member. There is no guarantee that the part-time resource will not get pulled away from your project to complete functional work. Nonetheless, a signed written agreement minimizes the risk. You, the project manager can use this agreement if it becomes necessary. Communication When a part-time team member is doing their “normal” job the full-time team members are solving problems, exchanging information and making decisions. It behooves the project as a whole to have a communication plan for the whole project team. Larger projects may use a push method of communication with an intranet, smaller projects should keep an up-to-date status and issue reports to bring the part-timer up to speed. Clear Expectations Let’s break up this blog with a bit of humor. Here’s a scene from Office Space. If you have ever worked in an office this is a must see... Ok, now that we’ve gotten that out of our system….Many times part-time project resources spend their time on work that is straightforward and unambiguous. The project manager must create a clear-cut set of responsibilities and expectations. The greater detail, the better to enforce productivity in the part-timer. Team Building A prerequisite for managing a part-time team member is to create a cohesive and content project team. Project Managers must facilitate the part-timer’s fit-on on the team. Nurture relationships to ensure the success of the part-timer’s fit on the team. A prerequisite for managing a part-time team member is to create a cohesive and content project team. Project Managers must facilitate the part-timer’s fit-on on the team. Nurture relationships to ensure the success of the part-timer’s fit on the team. In a perfect world, you will have enough full-time resources...
Read More »
Posted by maria bodkin on May 16, 2014 in blog
If the project manager is responsible for delivering the project, it behooves them to review all documentation. The Project Charter and other project documentation are sometimes completed before a project manager is assigned. If the project manager is responsible for delivering the project, it behooves them to review the business case, charter, etc., thoroughly, validate assumptions, and identify any gaps or areas that needs more detail. This is the time those hard communications are needed. The project manager should ensure that all of the questions are fully answered before the project is officially kicked-off. After deadlines, requirements, and budgets are set, expectations are much more difficult to change and the project manager is setup for failure. PMBOK suggests a project manager be assigned before the project is authorized. Let’s quote the boss (PMI): “A project manager is identified and assigned as early in the project as is feasible, preferably while the project charter is being developed and always prior to the start of planning. It is recommended that the project manager participate in the development of the project charter, as the project charter provides the project manager with the authority to apply resources to project activities.” Well said, PMI! In my experience I have been assigned or initially involved in a project before the charter is completed, approved, and issued. Have you had a different experience? Why did this vary from the above norm? How should a project begin? Hopefully you were not given project details when you were assigned to the project. The project manager must define the project in his or her own terms. Nonetheless you absolutely need to start developing your own understanding of the project goals, objective and deliverables. I would begin a project by asking the executive sponsor why we are doing this project. Subsequently determine who the project stakeholders are and solicit their opinion of why the project is being established. By getting their perspective the project manager can begin to write a draft of the project objectives. Determine the type of resources needed on the project Only the type of resources needed on the core project and the functional teams. Now that you have a clear understanding of the project objectives, you must communicate this “vision” to the functional managers. They must understand the project before they provide resources to the project. Depending upon the project manager’s organization (consultant or employee) the core project team is established. The initiation stage should first focus on SMARTizing the objectives. SMART is a mnemonic giving criteria to guide in the setting of objectives. The letters broadly conform to the words specific, measurable, attainable, relevant and time-bound. Now we can create the Project Charter. For more information on SMART objectives, please refer to Issue 5 in this blog series. It is critical every project team member understands their role as well as the project vision By the...
Read More »
