Throw out the idea of comparing Actuals to Estimates!

The imprecision of the communication from customer to salesperson to marketing to development to a designer to a coder to a tester to a system that does what the customer wants is immense. The estimates are often a translation of wild guesses made during this conversation. They reflect at best a guideline for the solution based on past work or similar projects. But it does not account for the impact of new technology, a different team skill-set and capability, or a different business domain.

Organizations will often focus on improving their estimation performance by building databases of estimate versus actual development metrics. Don’t compare actual to estimates! This will cause teams to focus on delivering within the tolerances of previous estimates. This often leads to an undesired effect; a compromise on quality, standards, re-factoring, database rationalization or other value added results of delivering quality, demonstrable functionality on time. This is the effect of sub-optimal measurement; measuring one single metric without paying attention to the larger holistic picture.

Increasing the accuracy of estimating by comparing actual hours worked to estimated hours worked is a suboptimal measurement. Comparing what the Team actually produces to a desired release date and release goals is a much more appropriate measurement.

What can teams do to improve the estimation process. Effective retrospective debriefs at each milestone, iteration checkpoint, or deliverable often will uncover the real challenges the team is facing. By learning and sharing the team will determine the true capacity to do work (velocity) of the team. And they will collectively become better at estimating the effort required to complete new units of work. Comparing to the actual metrics of past projects is comparing apples and oranges, and will not ultimately deliver the intended results.

Presenting at ProjectWorld & BusinessAnalystWorld 2010

I will be presenting at the 2010 ProjectWorld & BusinessAnalystWorld, May 17-20, 2010. This event is one of the largest project management conferences in the Toronto area, and is held at the Metro Toronto Convention Centre.

Topic: Building High Performing Agile Teams

Abstract:
There has been much written in terms of team effectiveness in traditional development projects. Recently, there has been a rapidly emerging area of agile development methodologies. These are dynamic, iterative approaches that are strikingly different in approach over more structured waterfall development approaches.

These approaches (of which Scrum, XP, Extreme, Rational Unified Process, and Evo are among) place new and unique challenges on the traditional development organization. In particular the impact on team development and effectiveness is a challenge that needs to be addressed.

This presentation will explore the research of high performing agile development teams as well as broader team effectiveness perspectives and develop a framework for building high performing agile teams. The framework will focus on practices around:

• Motivation and Reward
• Skills and Team Selection
• Organizational Impacts
• Leadership
• Communication
• Physical and Virtual Work Environments

Check out the Conference Website for updates closer to the event!

The new role of a Project Manager on Agile Teams

Project managers traditionally have been more focused on task management, administrative functions, and team direction. The Agile model is turning this on its head. In an ideal world Agile teams would be self-directing and self-managing. In reality there is a role for the project manager, but it needs to adapt to more of a coach and someone who can remove roadblocks from the progress of the team.

The project manager will serve as the social architect. The should facilitate the work process, and provide overall project leadership for developing the multidisciplinary task groups into unified teams. They should be focusing on fostering a climate conducive to involvement, commitment, and conflict resolution.

The project manager's concern for the project team's members and enthusiasm for the project fosters a climate with high levels of motivation and involvement with the project and its management. It also promotes open communications and a collective focus on desired results.

Ensure team involvement early in the project life-cycle
This planning and involvement is especially important for technology-based project work, where high levels of complexity, uncertainty, and risk - along with the need for innovation - make it nearly impossible for the project leader to work out a project plan that is seen as realistic, unless performance is the result of collective efforts by the entire team.

Build a high-performance image
Project leaders and senior managers can help build a favourable project image by making the project visible and stressing its importance through media exposure, management involvement, and budgetary actions, as well as by emphasizing critical success factors and professional opportunities and rewards.

Stimulate enthusiasm, excitement, and professional interests
Managers should try to accommodate the professional interests and desires of the individuals on the team. Interesting and challenging work is a perception that can be enhanced by the visibility of the work, management attention and support, priority image, and the alignment of personnel values with organizational objectives.

Ensure senior management support
The manager needs to negotiate with the sponsor and support organizations for the required resources; this individual must also obtain a commitment from management that these resources will become available when these are needed. Make sure the team believes that you have their back and will make sure they are being supported by the senior leadership.

Progressive and healthy leaders tend to foster creativity in their team. Healthy leaders naturally express a sense of trust that creates the environment necessary for the team to operate. They let it be known regularly and often that relationships are important, and that connections, interdependencies, and integration are at the heart of the team success.

Supporting Teams through the 4 Stages

There are many different models of team development, but we have all probably come across Tuckman's "Forming, Storming, Norming, and Performing" approach. Recognizing that teams have a dynamic that changes and adapts as the team builds experience with projects and with each other is important for the project manager to realize. And as a group facilitator we can support the team and work with the process, rather than try to push a team when it isn't ready.

Forming

In the forming stage the team is being orientated to the task. Team members look to understand the task and how the group experience will be used to accomplish the task. It is important at this stage to set the team ground rules, so people can start to develop some structure that will support stability and security down the road. As well, this is the stage where teams are trying to build the shared mental model of the business and technical domain of the problem. Support by bringing in experienced business and technical resources to kickstart the process through workshops.

Storming

This is a phase of all teams; some teams move through it quickly and some stay stuck in the quagmire for a long time. It is a time where there is heightened conflict between team members. It is characterized by a lack of unity, and key issues may polarize the team. And the team does not benefit from the security of strong interpersonal relationships that come later as the team gels. Support the team during this phase by over-communicating. Isolating issues from the personalities, and fostering a senses of accomplishment by mitigating and solving these problems starts to build the collective sense of accomplishment. Sharing in the early successes, however small, will start to build a feeling of unity. Understand that teams will go through this phase, and productivity may naturally suffer. Don't ask too much from the team at this point, and allow for a ramp-up of task velocity or capacity to do work in the early stages of the project.

Norming

Here is where the team really starts to develop of group cohesion. There is a more open exchange of relevant interpretations. This boosts creativity through the inclusion of differing opinions, and the team starts to really generate results. For the project manager, your role evolves from moderator to team facilitator. Drawing from and standardizing on developing processes, and working to remove and isolate the team from remaining roadblocks will allow the team to get down to effective task development.

Performing

By now the team has developed strong functional role-relatededness. The team becomes a problem solving instrument. Roles are clearly defined and enhance the task activities. The group is effectively providing feedback and adapting learning to improve the performance of the team. Support the team by providing mechanisms for mutual performance monitoring (feedback sessions, project retrospective checkpoints). As well, the team can become effective champions of what works and what doesn't work in the organization and should be given the task of sharing the lessons learned and best practices with the rest of the organization, and provide peer reviews of other teams that may be earlier in the team life cycle.

I am always interested in hearing what others have done to work with the natural evolution of new teams.

Lessons from an inexperienced Agile Team

Silva and her team tested the idea that the best way to learn Agile methods is putting it in practice in some active project. They uncovered some important lessons that can be drawn on if you find yourself introducing Agile to an inexperienced team.

The team ran into a lack of proper infrastructure. It takes time to setup the team space, meeting rooms, desks and IT equipment, and ideally development hardware, software and physical and logical environments. Plan early iterations or time prior to the project kickoff to set up some of these basics so the team can hit the ground running.

Often teams have little knowledge in the agile development methodology. This can lead to mistaken planning at first and inefficient team processes throughout the project. As well this can be compounded by lack of familiarity in the used technology on the project. This leads to inaccurate task size and effort estimation and sequencing. Teams may need to focus early iteration on training and ramping up the team, or bringing experts to seed the team. The technical skills of the team must be evaluated before planning the project.

During the project the team may run into issues with the high level of dependency among functionalities. This is a symptom of failing to design upfront functionalities that have tight cohesion internally, and are loosely coupled from other functionalities. Where this is not possible, functionalities need to be isolated using stub code or mock interfaces to allow development to continue in parallel.

Communication is key during an agile project, and inneffective communication will be compounded through lack of regular face-to-face meetings. Teams need to get into the habit of meeting daily in the scrums, and with the key clients at iteration kickoff and checkpoint meetings.

Finally, distractions were caused by team members have responsibilities on other project. Full time allocation to agile projects is a best practice. While this is not always possible, it should be a goal for the key developers and testers.


____________________

Reference: Silva, Liana, Santana, Célio, Rocha, Fernando, et al. Applying XP to an Agile–Inexperienced Software Development Team 2008

Collaboration and Diversity

Teams “tend to perform better when members exchange knowledge freely among themselves and outsiders." (Hyashi, 2004) Diversity among team members leads to better performance because of the range of viewpoints and experience of the different individuals.

The importance of information exchange on teams and the importance of diversity was highlighted by Cummings (2004). Diversity comes from geographic locations, functional assignments, reporting managers, and business units.

Diversity has its drawbacks, and these need to be managed to mitigate the impact on the team. Geographic dispersion can greatly complicate team communication and work coordination (Hyashi, 2004).

Project Managers need to be explicit about the importance of knowledge sharing. What are some ways to improve collaboration and sharing? Here is a brief list of the highlights:

• Cross-functional workshops and requirement/development sessions
• Hold “Knowledge fairs” or information sharing sessions. Have key knowledge holders run a "brown-bag" lunch seminars
• Tie sharing of information to the team and the rest of the organization to performance evaluations based on how well team members exchange knowledge
• Ideally co-location of the team, or regular face-to-face checkpoints to build trust and connections
• Use of team collaboration tools such as shared databases, email, instant messaging, conference calls, web meetings to breakdown the geographic barriers
• Building corporate knowledge assets such as wikis, centrally stored lessons learned, guides, best practices, templates

How else can we support diversity on our teams, and knowledge sharing inter-team and within the organization?

______________________________________________
Hayashi, A. (2004). Building better teams. MIT Sloan Management Review, 45(2), 5.

Cummings, J. N. (2004). Work groups, structural diversity, and knowledge sharing in a global organization. Management Science, 50(3), 352.

Impact to Consumer of Cap-and-Trade program may be understated

A recent report from the US government, it would appear on first blush that the impact to the average US household would be minimal. As mentioned in U.S. consumers spared big costs in climate bill, the average household would see their energy costs rise $114. Is this a true cost of the program to consumers? Is that providing a full picture?

According to the US budget, the amount the program would generate on an annual basis is $83 Billion USD (Remarks by the President on the Fiscal Year 2010 Budget). There are 114,300,000 homes in the United States (Current Population Report). The $83 Billion that would be generated are the offsetting allowances the energy industry will purchase. These are costs that would ultimately pass on to the consumer. That would equal $739 per household, quite a bit higher than the $114 suggested by Congress.

But let's take a closer look. The $83 Billion represents the costs of allowances purchased by the industry to cover emissions that could otherwise not be mitigated by reductions or offsetting programs. The industry would have also invested to produce these mitigations, costs they otherwise would not have incurred. From the performance of past market based mechanisms to control emissions, industry has been very effective at reducing emissions. We could be conservative and assume that 50% of the target could be met through mitigations and 50% through the purchase of allowances. The industry then would spend up to another $83 Billion on mitigations (not more, or the market would have bought allowances as that would have been less costly).

So the total possible impact to the industry would be as high as $166 Billion, for a total cost per household of $1448. Don't get me wrong, a market based mechanism like cap-and-trade has proven to be the most effective and efficient method to achieve emission reduction. But a fair assessment of the total costs, which will ultimately effect consumers, needs to be part of the discussion.

2009 PMI Lakeshore Chapter Symposium

I will be presenting on the topic of Developing Highly Effective Agile Teams at the upcoming 2009 Symposium, hosted by the PMI Lakeshore Chapter, the Professional Engineers Ontario, and the Canadian Management Consultant association.

More information on the symposium is here.

Leading Agile: Handling Support on Agile Teams

Leading Agile: Handling Support on Agile Teams
posted by Mike Cottmeyer has continued a real world discussion on how to handle building the current iteration, while still supporting other applications with the same team.

You mean we can't work in perfect isolation all the time ??

Setting up the "Agile" Team Room

A key element of Agile projects is the need for real time, dynamic communication. One way of accomplishing this is to co-locate the team, and use low-tech communication tools that are easy to understand, and easy for the team to keep up-to-date. For many organizations, in particular those that are new to Agile, how do you set the team space up effectively?

Physical space and co-location

The most effective layout for the physical team location is co-located desks and shared access to plans, status, next steps, and other project planning and management tools. The picture shows the physical space from an effective team. Team members are not separated from each other by offices or cubicles, but rather share desk and team space in an open concept environment. In teams that must be geographically separated, then tools for conducting virtual meetings such as conference call phones, instant messaging, shared electronic documents and tools are leveraged to minimize the distance and separation.


War Room
The war room is a shared team space for conducting meetings and sharing project planning tools in a real-time and dynamic manner. Ideally this is a physical meeting space near the team area. The typical elements of a war room would include:

• Team Structure - the basic "who's on the team", including contact information
  
• Client Organization Structure - Who are the stakeholders and how do they all fit together
  
• Team goals and objectives - Why are we here. What are we trying to achieve.
  
• High level plan, Mid Level Plan - The overall project milestones, and the key iterations and release dates, with the anticipated objectives or deliverables for each
  
• Roles and Responsibilities - A RACI style chart with the internal and external roles and the person on the team who is responsible
  
• Story Board - The stories for this iteration, what is complete, in-progress, and not started
  
• Purpose and Vision
• Client Deliverables - This may seem straight forward, but a reminder as too what we as a team are trying to deliver
  
• Client Phase Exit Criteria - What are we marching toward to complete the current phase and achieve signoff
  
• Team performance survey results - A summary of the latest team survey or other self-reflection the team has performed, and the key lessons we are trying to learn
  
• Story Stack - The scope of the project
  
• Communications Plan - Team meetings schedule and logisitics
  
• Meeting Agenda - The standard daily team stand-up meeting has a strict, short agenda so we can complete it within 30 minutes
  
• Issues and Next Steps - The whiteboard list of next steps, dates, owners, to be checked during each team meeting
  
• Risks - The whiteboard list of risks, impact, and mitigation that needs to be taken (with owner)
  
• Recognition Awards - Some place to call out great work by the team or individuals.
  
• Ground Rules - The team derived rules for respecting each other

Please share best practices or lessons you have learned to set up the agile project team. If you are looking for assistance to set up your team, please reach out and I will try and point you in the right direction.

Three Key Factors in the Project Closeout Phase

Project closeout is the final phase of the project and is the time where we can ultimately judge the success of all the planning, initiation, and execution of the project plan. Actions taken in this final stage determine the completeness of the project against its objectives, and the ultimate success of the project manager. I want to focus on three key factors of the closeout phase that all projects need to address: the importance of managing the closeout phase of a project, managing stakeholder expectations and achieving acceptance, and the impact of closeout on the project manager.

Managing Project Closeout Phases

There are lessons to be learned through the project closeout phase. Projects can be mined for best practices and lessons of its own that can be shared and leveraged across the organization.

It is important to plan and staff accordingly for the closure activities. Often people are often rolled off projects as soon as possible after completion of their deliverables. This can be prior to the closure activities being completed, leaving a smaller core team to clean up or the work is left incomplete. Often, the tendency is for the team to do what is necessary to achieve completion, without a sense of leaving the work in a state for long term support or enhancement. The customer’s final perception of the final product or deliverable is what sticks in their mind, and if the project team shortchanges this effort the organization will lose credibility, the repeat business, or the referrals.

Conducting a post-project review and capturing best practices to share with the community is a key part of the closeout phase. The intellectual capital is a competitive advantage but it is lost if this step is not completed. The organization should utilize a shared document repository and uploading tools and examples from the project are tremendously useful to new project teams. It is the ideal time to go about collecting the actual project performance data. This can serve as a basis for estimating the amount of work in future, similar projects.

Project closeout is an important time for celebration and recognition. The project team has spent a great deal of time and effort on the project, and often so has the various stakeholders. People need the time to celebrate and relish in the success. As well, if the project did not go smoothly, it is important to capture the lessons learned and give the team a chance to let go of the past so they can move on to future work.

Managing Stakeholder Expectations and Achieving Acceptance

In some ways the success of managing the stakeholder’s expectations, communication, and ultimately achieving acceptance of the project has more to do with the initial and planning stages of the project. Having a clear scope statement defined and agreed to prior to the start of the project is crucial to the success of the project. However, disputes usually surface at the end of the engagement as the final deliverables are being produced and delivered. The best way to reduce the impact of project disputes is to avoid them.

In the event that issues arise during the closeout phase of the project, it is important to have a dispute mechanism and escalation process. The communication plan is the starting point for developing a regular habit of discussing with the client the current state of the project and the issues and risks that are anticipated.

The lesson learned is that an organization should spend more time with the stakeholders, understanding their business, building a relationship, and developing the work products together, and the focus on the contract is secondary. By being on the same side of the table as the stakeholder, having a strong relationship in and outside of work, and showing them that you can be trusted and fair, goes a long way to help disputes be managed without damaging the relationship.

Impact of Closeout on the Project Manager

Project closeout is an important time to focus on the team, with celebration, recognition, feedback and compensation discussions occurring as part of this phase. But as a project manager, it is important to take care of yourself as well. Project management has some built in stresses, and at the closeout phase project managers are dealing with the same issues around closure, moving on, acceptance and recognition as the rest of the team.

Common Pitfalls When Moving to Agile

Moving your organization to Agile is akin to moving to a new country with a new language and culture. No amount of training can prepare you for every challenge.

I have presented versions of this presentation at Project World 2008 in Toronto, and for the PMI Southern Ontario Chapter, as well as in my work consulting with clients on transitioning to a more Agile Methodology. People have been asking me to make it available, so I am pleased to post it here.

Key objectives of this presentation:

• Learn the key benefits of Agile Methodologies versus more traditional approaches
• Understand the major issues organizations face when adopting agile processes
• Recognize the critical success factors that are needed to be successful with Agile

The PDF version of the presentation available in the document: Common Pitfalls When Moving to Agile

What Questions Should be Answered at the Start of a Project?

Effective teams do not just happen naturally, and planning for effective teams is a planned process that can have a positive influence on the success of the project. The following questions should be asked of the project manager prior to the project getting underway:

• Is the team aligned to a common vision?
• Are there clear roles and responsibilities across all team members?
• Has the team articulated a Code of conduct and Ground rules? Is it being followed?
• Have the skills necessary and a training plan been established to develop the skills on the team?
• Is there an established and documented communication plan?
• Has the team set up the physical space and co-located?
• Has the team established a shared war room with the required artifacts and communication tools?
• Has the team planned a project kickoff workshop to ramp up the team?
• Is there a team growth plan in place?
• Is there a team performance plan in place?

Project teams are a common and established method of organizing the resources on a project. There is, however, a wide variation in the effectiveness of these project teams. Ineffective teams have low morale, low performance, high turnover, and are generally less capable of delivering on the project scope. The goal of the project manager is to plan for and establish an effective team that is aligned to project goals, develops a strong sense of interdependency and is highly functional and successful at meeting or exceeding project objectives.

Key Processes during the Project Initiation Phase

The initiation phase is a critical, initial step in the successful delivery of projects. Let's review the best practices in the industry regarding initiation phases, as well as the typical deliverables. This is the time to set the team and the project up for success in the subsequent phases.

Project failures occur frequently and there are specific failure modes. The Standish Report showed that over 70% of IT projects were either challenged or impaired. And by "challenged" I am referring to projects that were over budget, over schedule, or delivered with fewer than promised features or functions. Impaired projects are those projects that were canceled outright. The main problems I have encountered in my travels have roots in the initiation phase:

• Lack of a Business Strategy - The results of a project effort must support the organization’s strategic goals and business strategy. The organization’s business strategy and strategic objectives should be used as a starting point for investment selection.
• Lack of Stakeholder Support - Sometimes there is a recognized need for a project, but there is no one to champion the effort. People may or may not support a project for a variety of reasons. Management executives who control funding must have an interest in the project success. Top-level management buy-in must occur at the inception of the project and be visible throughout the life of the project.
• Lack of Resources - Many resource problems relate to funding and assembling the resources needed to perform initiation activities. Locating people with the right skill set can be difficult, and the difficulty increases with project complexity. Funding for project initiation activities is often constrained or unavailable.
• Lacks of Consensus on Project Objectives - The most difficult commitments to obtain are from customers and stakeholders. Frequently, there are many different ideas about what the project should include and what the project will develop. It is crucial to have concrete agreement on project objectives.
• Lack of Coordinated Leadership - During the initiation phase, stakeholder coordination can be difficult. This is frequently the result of many individuals attempting to influence or lead the project at the same time. Such environments can create an atmosphere of faulty or disjointed decision-making.

Many of the issues that challenged project face can be traced back to improper planning in the initiation phase. A successful project is one that delivers expected results, and defining the expected results and providing the necessary processes and resources to achieve these results is the ultimate goal of the initiation phase. These key processes are:

Project Identification
The initiation phase answers a number of key questions for the project team and the organization. The first is how we identify of the project. While this may seem obvious, it helps define the boundaries around the project and differentiates the project from others in the organization. It includes the name of the project and the designated project manager. As well there should be a brief summary of the project purpose, scope, time frame and resources required.

Development of the project description statement is an essential and defining process in project initiation. What the project is to accomplish must be described in simple high-level terms at the beginning of the project. The statement should describe who the project is for, what must be done, and why it must be done. This statement is the foundation for defining the scope of the project.

To arrive at this statement, the project manager or team should perform an abbreviated analysis of the assigned project. The project description statement will: describe the general approach to development; describe the basic characteristics of the required product or service; identify the beneficiary; and, identify the purpose served by the product or service delivered.

Business Justification
Establishing the ultimate need or benefit of the project is an important question to answer during the initiation phase. The customer of the project is identifies as a unique stakeholder that would ultimately receive and benefit from the output of the project. They are the source of the need the project is intended to meet, either as a problem to solve or as an opportunity to exploit. The initiation phase should establish needs such as requirements, features, functions and the tangible and intangible benefits such as revenue growth, increased market share, cost savings or avoidance, or regulatory compliance.

Scope Statement
The product and project scope is defined at a high level to provide the bounding assumptions around the size and effort required for the planning and execution phases of the project. Product scope defines the characteristics of the product, service, or result of the project being undertaken, and project scope describes the projects deliverables and the work required to create those deliverables. This may not be completely defined at this stage, but enough detail is specified for further estimation and planning activities. Part of the definition of scope also includes the procedures to be used for making and documenting changes to the project. The Project Manager, along with the project team define the scope of the project and identify the preliminary budget, high-level schedule and quality standards to complete the project.

Project Methodology
The initiation phase should establish the overall project management approach being undertaken. The methodologies being employed and any relevant PMI or other standards that are to be used are established. The methodology provides the way in which the project will produce its objectives and deliverables.

As well a during the initiation phase you should develop Initial Project Plan, where the Project Manager and Project Team identify all Stakeholders and document their involvement in the project, develop means of communicating with them, and compile all documentation created during Project Initiation to produce the Initial Project Plan.

Stakeholder and Communication Strategy
A communication strategy is developed during the initiation phase to identify the communication required between the project stakeholders and the project team. A major component of the communication strategy is identification of the various project stakeholders. It can also provide the method and criteria for the project sponsor to accept the specified project deliverables as complete and adequate.

Risk Management
It includes an approach to identify and manage assumptions, constraints, and known risks which can be anticipated to have a major impact on the process and/or outcome of the project and which require decisions or actions by the project sponsor or team. At the initiation phase, risk management involves a high-level examination of what could go wrong as well as what opportunities could materialize. During the initiation phase the team should 1) identify potential risks, 2) assess their impact, and 3) develop strategy and tactics for dealing with them. What is important here is that there is a rational and acceptable plan for dealing with the risk associated with a project.

Project Costs
Finally, to support the project business case, the resources and costs associated with the delivery of the subsequent phases is assessed. This may include the financial, personnel, and material resources (such as facilities, equipment, supplies, and services). A completed initiation phase needs to provide the impact as well to provide the information needed to evaluate the project against competing demands in the organization.

Summary: Key Project Initiation Phase Deliverables

• Project Charter – A document that provided the high level statement of work and scope description
• Kickoff Meeting – A meeting to establish the project, introduce the objectives, define processes and set direction, and achieve buy-in and momentum amongst the project stakeholders
• Project Repository – A central and accessible electronic store of the key project artifacts
• Scope Statement – A document of the project and product scope, including requirements, deliverables, and binding assumptions
• High Level Project Schedule – A roadmap of the key milestones and deliverables of the subsequent phases of the project
• Quality Management Plan – A plan for the management of the quality of the project, including change management, defect management, testing and quality assurance reviews
• Preliminary Budget Estimate – A financial summary of the resources and costs associated with delivering the project
• Risks and Impacts – The identified risks, probability and impact assessment, and mitigation strategy
• Communications Plan – The types, methods, objectives, and frequency of communication vehicles that would be used by the various stakeholder groups
• Description of Stakeholders – A listing of the various stakeholders and their drivers and objectives
• Business Case – The business drivers and benefits for doing the project

Welcome

Thank-you for taking the time to come to this site. I will be using this blog as a mechanism to start a conversation on a variety of topics near and dear to me (and hopefully you).

You can read up a little more about me in my Profile, but I am going to draw from my experience as a Project and Program Manager in the Energy and Utilities sector to share new directions in project management and how to successfully deliver projects in today's world.

I am also interested in hearing from you. Please subscribe to this blog to stay informed on the newest developments. And I encourage you to comment and contribute to the discussion by clicking on the comments link below each post. You can contact me at rmcgeachy@gmail.com and let me know of topics you would like to hear more about.

Coming Up

I hope to post once or twice per week. Looking forward, I will be bringing up the topics of

• Transforming your organization to an Agile Development model
• Developing high performance work teams
• Modeling business and application architecture in an Energy domain

. . . as well as pointing out developments in the Energy and Project Management domains and how they might impact businesses today.

Take care, and I hope to see you again.

Rob