Sunday, 2 March 2014

eteoBoard - The innovation for distributed agile developement

ETEO - Discover how distributed agile software development works! For more information and orders please visit: http://www.eteoboard.com

ETEO in German stands for "Ein Team Ein Office" - one team, one office. This concept of the Saxonia Systems AG offers the possibility to work in distributed teams at different locations on the same projects.

Experience within this video the advantages of the virtual project room where all the team members are constantly connected. The intuitive handling of the eteoBoard offers each team member the opportunity to keep track of all activities during the whole project. This interactive touch screen -- the eteoBoard -- was specially designed for this purpose.

Discover how distributed agile software development works.

Regards,
Rui Simões

Become a Project Management Professional (PMP) ®

PMI’s Project Management Professional (PMP)® credential is the most important industry-recognized certification for project managers. Globally recognized and demanded, the PMP® demonstrates that you have the experience, education and competency to lead and direct projects.

This recognition is seen through increased marketability to employers and higher salary; according to the PMI Project Management Salary Survey–Seventh Edition, certification positively impacts project manager salaries.

Who should apply?

The PMP recognizes demonstrated competence in leading and directing project teams. If you’re an experienced project manager looking to solidify your skills, stand out to employers and maximize your earning potential, the PMP credential is the right choice for you.

PMP Eligibility Overview

To apply for the PMP, you need to have either:
  • A secondary degree (high school diploma, associate’s degree, or the global equivalent) with at least five years of project management experience, with 7,500 hours leading and directing projects and 35 hours of project management education.

    OR
  • A four-year degree (bachelor’s degree or the global equivalent) and at least three years of project management experience, with 4,500 hours leading and directing projects and 35 hours of project management education.
This is an overview of the requirements. For complete details regarding the PMP eligibility requirements, please view the PMP Handbook for further details.
If you do not meet the PMP eligibility requirements, you may want to look at the Certified Associate in Project Management (CAPM)® certification.

How to apply and prepare for the exam

Maintain Your PMP

As part of PMI’s Continuing Certification Requirements program, a PMP credential holder will need to earn 60 PDUs per three-year cycle. To learn more about the program, what are PDUs, how to earn and claim them, as well as step-by-step instructions on how to renew your certification, watch the CCR video. You can also reference the latest PMP Handbook found on PMI.org
If you’re ready to report your activities, visit PMI’s online CCR system to report PDUs and view your certification records. You can download a printable PDU activity reporting form.
Regards,
Rui Simões

Practical Project Management & Tracking Using Microsoft Project

Microsoft Project has an incredible amount of features and functionality and furthermore allows the Project Manager to use. This guide help you to avoid "death by MS-Project" from the moment you first create the new Project.

Building a Business Case for Your Project

In order to get stakeholders or management to approve your project, you will need to build a business case to demonstrate why the project is needed and what the benefits of the project will be when it is finished. The reasons and benefits of your project may seem perfectly obvious to you and others who are intimately involved with it, but to stakeholders and other decision makers it may not be so obvious. Oftentimes, they are dealing with a myriad of different business units and objectives and tasks that need to be done. A well-prepared business case can help your project standout in the crowded field of everything that is happening in the company and might just be the key to getting approval and finances for your project. Here are the basic steps for creating the business case.

Step 1: The "As Is"
The first step is to document the "as is". If you do not understand where you have been (or where you are currently), how can you demonstrate where the project is going to take you or the company? This applies to software development just as much as it does to business organization or any other industry in which projects are executed. Documenting the "as is" should involve a careful evaluation of the current business model and the tasks that are completed by the people who are directly involved in the processes. You might need to interview certain subject matter experts or follow a day in the life of the workers who are on the front lines of the business in order to document the "as is". Most importantly, all assumptions must be challenged and researched so that there are no surprises down the road when the project begins to change the "as is" to something new and better.

Step 2: The "To Be"
Once you know where you are or where you have been, then it is time to document the "to be". This is your time to shine by showing off what the project will do for the business. It might be a better software system or a new business process flow. Alternatively, it might be restructuring the office organization to provide better support for the sales people. Whatever your project is going to do for the business should be documented just as carefully as the "as is" was documented. Again, challenge all the assumptions, work to evaluate carefully everything the project is going to accomplish. The final documentation of the "to be" becomes the initial scope statement for the project.

Step 3: Going From the "As Is" to the "To Be"
Now that you have a picture of the "as is" and a picture of the "to be", it is time to document the steps that will take you from the starting point to the end of the project. This does not have to be a detailed project schedule or task list, but it should give a high level overview of how the project team is going to take the business from one point to the next. This overview should include the resources and time that will be involved in the project. This road map will show the decision makers and the stakeholders how they can help make the idea into a reality and get the project off the ground.

Step 4: The Return on Investment
The last part of the business case is to show the return on investment. This is a vital piece for the stakeholders involved and the organization’s management. Answer the question of how this project is going to help the business. If the organization is willing to provide the time and resources to execute the project, what are they going to get out of it? This may be something like improved productivity for office staff or quicker processing of documents in the office. If the return on investment can be quantified into dollars in the form of savings or returns, then that will be a great help in building your business case; it is difficult to argue with hard numbers. Of course, all assumptions about the return on investment will be challenged closely, so be sure to do your homework very carefully when creating your business case.


Managing the Project Document


The importance of an effective document management strategy for project success

During the life cycle of a typical project, a project manager can produce up to fifty different types of documents to facilitate the planning, tracking and reporting of the project. Documents range from feasibility studies, resource plans, financial plans and project plans, to supplier contracts, post-implementation reviews, change request forms and project status reports. The fact is, the manner in which project documents are managed by project leaders can either be the driving force behind a project's success or the bottleneck that often places a project in despair resulting in its failure to meet its time line, budget and scope.
In this paper, I will be discussing the power behind an effective document management strategy for project managers and its pragmatic impact on improving your visibility into a project's status to better respond to the inevitable reality of change occurring in your day-to-day work.

The Role of the Project Document

The primary role of a project manager is to manage the unexpected. The concept of planning by its very nature is designed to mitigate and manage the unexpected. As a part of the planning process, most project managers would agree that the project document plays a central role in strategically developing the best possible plan and to effectively communicate progress and status updates to all stakeholders. More importantly, the manner in which the project document is managed will determine a project manager's effectiveness in responding to the unexpected.
Prior to discussing the management of the project document, let us define the "Project Document" and how it fits within a typical organization's project management workflow. The project document is a self-contained document that details your organization's unique steps in initiating, planning, executing and closing projects. In fact, the chosen project document types, the format they are produced in and the manner, in which they are organized, in their very essence, is what makes your organization different in delivering projects. Experienced project practitioners are excellent in "Templatizing" their project documents. The reuse of successful project plans, complex business-case documents, standard contracts, detailed specification sheets, and project status reports are necessary for a project manager's effectiveness in balancing the evils of unmanageable paperwork that can impede their ability to focus on their core competencies of managing the project and the involved stakeholders. However, a project template is only as good as the individual managing its use. What sets apart great project managers from good project managers is their ability to minimize their administrative role in producing project documents while maximizing their strategic role in managing the people that will deliver a successful project. In order to achieve this, project managers must follow some basic rules in developing key project documents covering all phases of a project's life cycle.
Although the project document workflow will vary from organization to organization, good project managers will develop a number of basic project documents in order to maintain high standards in the delivery of projects. A standardization of the documentation is typically seen in the following project phases:
  1. Project Definition or Conception: In this phase the project charter document is at the heart of initiation. Defining the charter and the details surrounding the project's objectives are key drivers in building the project's road to success.
  2. Project Planning: In this phase, the project leadership plans for the unexpected. The documents detailing the project plan, scheduling of resources, client agreements, and risk management, house the strategic details of the project.
  3. Project Execution: In this phase, tracking and reacting are the name of the game. Here the project documents are delivering the actuals and updates to the project plan. Tracking cost, time, physical progress and emerging issues are documented in this phase.
  4. Project Closure: In this phase, documents will detail outstanding issues and/or deliverables, review of project outcome, and best practices project management processes to be utilized for future use.
Once again, these project phases are guidelines to what document types play a critical role within the project life cycle. In the upcoming sections of this paper, I will be highlighting the obstacles created by a poor document management strategy and how these issues can be addressed with the right strategy in place.

Document Mayhem

Paper Pusher! Bureaucrat! Those are the last words a project manager would want to be labeled as. The reality is, ineffective project managers can easily fall into the trap of producing piles of paperwork that can cloud their judgment leading to the inevitable demise of a project's failure. When poorly managed, the project document can easily be used to conceal the reality of a project's status, create confusion and frustrate those who want answers, as well as those who need to deliver. In fact, the wrong use of a project document can minimize the strategic value project managers' play in a project's outcome. It is for this very reason identifying the project document bottlenecks is as important as the effective use of project documents.
The primary issue project managers' face when managing the multitude of documents is the sheer volume of information that is contained in all the project documents that needs to be shared among all project stakeholders. Although the collection of project information is essential, many project managers are challenged with the ability to effectively access the most relevant information across all project documents to quickly respond to project bottlenecks and provide status updates to their stakeholders.
The reasons for this predicament laid in the typical manner most organizations treat their project documentation. Most project organizations do not have a document strategy in place to ensure the consolidation of information and the movement of project documents among project stakeholders. As a result, the poorly managed project documents produce the following symptoms:
  • Lack of Visibility: Project managers and stakeholders have an unclear picture of project statuses and all related work. Project documents are treated as self-contained islands of information that do not exchange information between one and other. Moreover, these documents result in redundancy of information contributing to the lack of visibility.
  • Weak Security: Poor security measures are in place with no business rules and workflows to treat sensitive documents. This can result in critical project information ending up in the wrong hands and ultimately derailing a project's objectives.
  • Loss of Data: Many project management organizations do not have the processes and ability to store all their project documentation in a single repository. Typically, the information in these documents can be potentially lost, difficult to access and can contribute to the lack of data integrity that could potentially end up in decision-making reports.
  • Limited Collaboration: Project documents (e.g. spreadsheets) are often managed as unstructured data sitting in emails, on desktops and in paper format. More often than not, project documents are not easily shared among project stakeholders that may need to access information from multiple locations.
Identifying the issues surrounding document management is an important first step in eliminating document mayhem in your projects. The next step is to adopt a best practices approach developed by document management experts whose business is to streamline the management of documents.

The importance of implementing a good risk culture in Organizations

Risk culture is a term describing the values, beliefs, knowledge and understanding about risk shared by a group of people with a common purpose, in particular the employees of an organisation or of teams or groups within an organisation. 

This applies whether the organisations are private companies, public bodies or not-for-profits and wherever they are in the world.

Use a simple A-B-C approach (Institute of Risk Management, 2012) as helpful in understanding how culture, and hence risk culture, works in practice:
  • The Culture of a group arises from the repeated Behaviour of its members;
  • The Behaviour of the group and its constituent individuals is shaped by their underlying Attitudes;
  • Both Behaviour and Attitudes are influenced by the prevailing Culture of the group.
The next image describes a Risk Management Process: