Guerilla Project Management

Team Topologies and Real Life Experience

2024-03-28T10:32:00.020+02:00

During my (long-lasting) reading of the book Team Topologies, I paused quite often because I found the book hard to chew. The book is rich in concepts that did not, at least in the beginning, hit close to home and seemed quite abstract to me. Having said that, it got better when I reached the middle and I actually started to compare the project I am working on since 5 years now with the concepts presented in the book.

I mapped our current team organization on the book's concept of a complicated subsystem team. In such teams, the knowledge of individuals and the stability of the team are of paramount importance, something that the book argues for and I found out on my own during the lifetime of this project. Actually, the book argues that generally the stability of the team is important, an idea that contradicts some management philosophies that encourage personnel mobility and rotation. The book also argues for being sensible at the level of the whole organization as an environment for the teams and criticizes "reorgs", especially recognizing that many are done for the sake of power and political games - ouch! Something I've seen happening and is indeed worse (my opinion, not the book's) than any other anti-pattern for team productivity.

An interesting concept and among the first ones introduced is Conway's law: the (demonstrated) fact that systems' architecture follows teams' organization and viceversa. I debated the idea with a few people involved in IT and they all had an "Aha" moment; they felt that intuitively they can confirm this law, but they were surprised there is also a scientific paper behind it. Connected to that comes the idea that as an architect, one must take the time to organize the teams as well as draft the architecture (inverse Conway maneuver). This is something that I never witnessed as a practice in any organization, although I can recognize that genuinely the teams I work with tend to reflect the architecture.

The other surprising law that the book introduces is Dunbar's number: around 9 to a maximum of 15 of people make a good team. This was my "Aha" moment, because our team has naturally evolved to around 10-11 people and the efforts to expand that and absorb more members were perceived by the team as a huge effort. Here comes another neat concept in the book, cognitive load - I used to call that "mental energy" but I agree that "cognitive load" is much better to express the limited capacity of human brain to accommodate many difficult topics. By capacity, I am not referring to time but rather to this mental energy that can be only allocated to this amount of problems. So the cognitive load for our team, that was already handling a complicated subsystem, was already high and we could not accommodate easily the absorbing of new people.

Then, how to achieve bigger objectives with such a constraint as the Dunbar's number? By having fractals of teams, teams of teams that all respect Dunbar's number. These will be tribes and divisions working together under some patterns of communication that are described later in the book. It all sounded prescriptive and without the usual amount of "it depends" that business books like to add just to be on the safe side, but I made an introspection remembering all the successful projects and organizations that I met/worked for; I don't remember any in which the managers were aware of such concept and yet I can assess now that in the successful ones, the org chart seemed to naturally fall into this pattern.

There is a special subchapter on anti-patterns referring only to: ad-hoc teams and project based teams, but afterwards the anti-pattern term is used in many contexts such as "silos" or "DBA team", "OPS team", etc. This was the hardest to grasp for me because I could not exactly make a distinction between do's and don'ts and I see these "anti-patterns" working to some extent in real life. I kept wondering what is a complicated system team but a "silo"? We run a complex system but we must be doing something right because it seems our system is performing for the outer world. We do have a separate OPS team and their work is invaluable for this smooth running.

The one anti-pattern of project based teams that dissolve after a project is considered "finished" is something I could recognized. I practiced that and saw it in practice for many many years. It was only but in my last project, when I finally agreed to take on my first big maintenance contract, that I witnessed how the true value delivering starts after the "implementation project" finishes. Contrary to the usually practiced setup in which maintenance is taken on by "the maintenance team", we had to use the same team for maintenance because of how complex our system was and how difficult was to bring in new people. I soon realized the delivery flow was actually quite smooth in this setup.

That being said, I am done commenting how great my current team is 😀. I believe we are currently being overrun by how complex our system is, that is, according to the book, we are reaching our maximum cognitive load treshold. According to the book, when this is reached, we should choose a fracture plane and split into several teams. That will not happen soon, but at least we have what the book calls an inner topology, that is we have a stream-aligned sub-team, "a sub-team" of 1 person enabling other people and a complicated sub-system "team" made also of 1 person. This acts a bit as an isolation to simplify life for the stream aligned team and reduce their cognitive load. Again, I am mapping this topology on the concepts in the book, but it evolved naturally before I even came across this book. I personally believe this evolution, which I did not necessarily see in other cases, was thanks to a favorable environment in which the team was allowed to perform; we were invested with trust and to some extend isolated from corporate politics, but also kept from growing too large (mainly due to budgetary reasons).

So the four fundamental team types that this book advocates for are Stream Aligned, Enabling, Complicated System Team and Platform team. It goes ahead to define ways of communications between such teams and, surprisingly for me at the time of reading, it declares more communication is not necessarily better.

Point taken, moving on to the neat concept of "X as a service" interaction and DevEx. "X as a service" is mainly allowing other teams to consume the services provided by a team based on API, with minimum communication required. DevEx is short for Development Experience, some set of rules of coding, documenting and other practices meant to explicitly reduce the cognitive load on the teams using the artifacts. The API and DevEx practices translates also in communication flows for the team. In my current project, we have quite a few teams using our complicated system based on API and I used to want to understand the whole context, but now I realize more information from the outer world might just bring the cognitive load past our treshold.

The other team interaction types presented in the book are Collaboration and Facilitating and I find the names quite self explanatory.

The conclusion of the book is that in order to maximize the effectiveness of the organization, one needs a combination of well-defined fundamental team types and well-defined communication types. My personal comment is that in a nurturing environment, the teams will naturally evolve to respect that. Probably, organizations cannot afford the time to go through this natural evolution so the explicit addressing of Conway's law, Dunbar's number and interaction types from the beginning is indeed needed.

Using Agile Accelerator to manage your Salesforce implementation

2018-04-16T14:21:00.002+03:00

I was recently involved in a Salesforce implementation in cloud. As I wasn't familiar with their technology, I kind of accepted the suggestions of senior Salesforce consultants regarding what tools to use for managing the project and managing the support for the live environment. I am a huge fan of tools like Jira and Redmine, which I recommend to every client, but in this case I took the advice to use Agile Accelerator, which is actually a plugin for Salesforce. This is going to be replaced soon by Work Manager which also has a nicer look and feel.

I had an overall positive experience with this tool, it helped tracking everything and I was able to find on the spot who's doing what (I had a big team of 25+ people that was distributed internationally).

You can define work items that can be User Stories, Bugs or tasks:

One can see the list of all work items in a simple list and can use the seamless filters and customizations that are standard in Salesforce. I used a lot the filtering by Sprint, so then you can see a list of issues and functionalities that are planned for release in a Sprint.

There is also a more visual way to see the work in progress in the Kanban Board:

For sure it was useful to have direct integration with the Accounts, Cases, etc, especially in the testing phase.

On the minus side, I would have loved the Gantt Chart that I was able to generate in Redmine (and that was always the star of all Steering Committee presentations, with 0 effort to create it from my side 😀). This looks amazingly good, and it would be a nice add-on if anyone from SF listens:

I also felt like customizing the workflows for User Stories and Bugs, but that was not possible without the help of a consultant. In consultants we are always short in IT projects 😀, so the workflows that I use and consider best practices had to be twisted to map the application.

Though I felt like creating a Gantt chart, I never felt like I needed to use Excel for managing the US and the bugs and to me that is top recommendation for a PM Assisted Tool. Enjoy!

Rebaselining

2015-12-10T11:21:00.000+02:00

Rebaselining is a Standard Operating Procedure for Project Management that refers to the process of revising a project’s budget. A baseline means a set of figures meant to be used as a base for measuring variances and it can refer to many other things besides money (e.g. timeframe, response time, etc). However for the purpose of this document we refer to the baseline only in the context of a project’s revenue and costs ($ and effort expressed in mandays).

Usually, companies refer to baseline as the P&L established during the bid phase (we will call that “the bid baseline”). However, the baseline is not a static figure; once we understand there is no way we can reach a certain baseline, there is no point into trying to measure against it. This is why baseline can and has to be changed once there is information that the original (bid) baseline cannot be achieved.

It may be found that bid assumptions may need to change as a result of the scope validation and project workplan development processes that would have impact on the project’s costs. Or during the project’s execution and control, project financial changes may occur that would lead to the need to rebaseline the project’s budget. These could relate to changes due to rate changes, amendments and/or unforeseen project conditions.

It is the project manager’s responsibility to bring these changes to the attention of management and present a case to re-baseline the financial cost expectations for the project. The project manager would need to obtain approval for the new budget before it can be used for calculating variances and must obtain approvals from the same approvers that approved the original budget to rebaseline the project’s budget, specifying the business requirements for the re-approval.

This policy is not to be interpreted that costs overrun will be easily accepted. Usually, the management will challenge any such request and Project Managers will need to make a good case in explaining their position.

Purposes of rebaselining:
In case of change requests, it is obvious we want to track the project against the whole funding provided by the client.

In case if internal changes or unexpected events that impact the costs, we need to acknowledge them and attempt to control the changes just as we would do in the case the client has initiated the change.

In case of “scope creep” or customer not fulfilling their obligations, the PM will immediately signal this to the client, understand the impact, obtain new estimations from the team and commit to the new estimations. If the PM fails to obtain additional funding for the change and for commercial reasons the team gives away free days, the PM should still inform the retain the amount for giving their company an edge in further discussions.

In case of plain misestimating, the PM must immediately assess the impact, obtain new estimations from the team and make sure they commit to the new estimations. This will allow the management to ensure there will be no further slippage. The PM must also analyze what caused the error in estimating and propose the necessary update in the estimating techniques used in the company.

Triggers for rebaselining

Any Change Request that modifies the Revenue and will be not handled as a different project.
A Change in services costs (own or subcontracted) that is outside the range of +-10% of total costs.
A change in external costs that implies acquisition of new equipment, new licenses or new subcontractor, regardless of amount.
The new baseline must replace the old baseline in the project progress report, while keeping the old baseline for reference.

A good policy is for PMs to inform on a necessity to rebaseline because of costs overrun as soon as they can predict a cost overrun that might impact the budget (that is, before the costs actually occur).

Risk Management at the Source - Part 2 - Monitoring and Controlling

2014-09-04T19:41:00.001+03:00

Initiating and Planning provided you with many opportunities to foresee risks and mitigate them early on. If you have not read the post, make sure you do because in Monitoring and Controlling your life will be much easier if you were able to follow some advice listed there. Initiating and Planning is the best project phase for mitigating risks.

If life was tough and you couldn't address the risks at the beginning of the project, there is still a chance you could do it while monitoring and controlling. The techniques used in the monitoring and controlling phase are also useful for the situation when you take on a project after it had begun and had been initiated by somebody else, possibly less skilled then you. The project might already be in trouble if the risks where not address early on, so your main challenge might be to find time for preventive actions while firefighting the current problems. The obvious advice for this situation (and listed in every Time Management book printed) is to work on a Urgency-Importance framework; that is to handle first Urgent and Important issues, then Important but not necessary Urgent issues. It sounds simple, but it takes a cool head and a bird's eye overview on the project to resist pressure to act on the Urgent issues - which is why Project Management requires some maturity.

That being said, here is the promised list of techniques:

Include key risks in Project Progress Report and Steering Committee presentations, including expected action plan, deadline and responsible. This might come to you as a no-brainer, however I have seen many Project Managers not exposing risks because they don't want to "upset" the customer. Others, to the contrary, like to give such a list to the customer in order to lower expectations but fail to provide a solution and action plan with them, which makes the customer and the team shrug while no constructive action is taken. Do this also to make sure client and team take risk management seriously and understand Risk Log is not an academic exercise.
Circulate Project Memos with regard to risks if in-between reports. This will ensure risks get all the attention and implication from involved parties.
Include contingency for highly probable risks in the estimated costs of the projects. This will mitigate debooking revenue due to risks materialized and fluctuations in the revenue forecast.
Monitor actions of non team-members staff involved in Risk Mitigation as you do for your project team. That includes monitoring deadlines for project sponsor, client staff, sales staff risk-related activities. Risks are often related to entities outside your project team. Monitoring these entities will mitigate the risk of stalling in important decisions, and that influential people don't timely use their power to help your project.
Depending on your delivery methodology, you can use various documents to mitigate risks. For example, use the Testing Strategy to clearly split roles and responsibility between you and your customer. This will ensure the customer not performing their tasks thus delaying the project.
Use the Testing Strategy to define testing system information; release procedure, bug tracking procedure, acceptance criteria for application (e.g. “no critical bug, no more then 4 medium bugs and plan of action for all bugs”), definition of bug and new feature request in the testing strategy. Pre-approve the document (gain approval before testing begins). This will mitigate the risks that testing is delayed because of misunderstandings between the development and testing team, unrealistic expectation that the application performs perfectly, discussions over bugs vs new functionalities, unrealistic expectancies that new features will be considered bugs. And in the end mitigate an important risk of all projects - scope creep.
Use the User Acceptance Testing strategy to avoid the common pitfall of transforming UAT in an analysis workshop gathering new functionalities requests. You can do that by planning and pre-approving a set of goals, scope and assumptions in the UAT Strategy.
If you need to perform data migration, create and use the Data Migration Strategy document to mitigate specific risks related to data migration and pre-approve the document. Include data migration sources in the conversion strategy; this will make it difficult for the customer to communicate later there are other source systems;
Include data correction and coherence assumptions in the conversion strategy; this will ensure all parties are committed to giving clean data for conversion;
Include conversion procedure, including manual and semi-automatic procedure in the conversion strategy; this will mitigate the risk of unrealistic expectations that all data will be imported automatically;
Include migrated data tests and acceptance criteria in the conversion strategy (e.g. quantitative through counting in the database; qualitative through samples, visual inspection, formulas). This will mitigate unrealistic expectations that all migrated data can be tested for correctness.
Use the Training Strategy to propose a several layers of training that include readiness assessment, re-training sessions and workshops with end-users after go-live. For most projects, one initial training is not enough and end-users end up rejecting the system.
Perform initial orientation for own and customer team and have the materials ready to perform orientation whenever a new member arrives. This will mitigate Project Team not knowing where the project is heading, new members disrupting the direction of the project, or staff (including customer's) not understanding their role in the project.
Use Post-production Strategy to assign level 0 and level 1 support to key users, with clear responsibilities for the customer. This will avoid trivial issues or operating errors to get to the implementation team, saving your team's time for the real important issues;
Include a bug tracking system working procedure in the post-production strategy that states who should check for duplicates and trivial issues before they are assigned to the implementation team; also to avoid bugs arriving on different channels to the implementation team.

Happy Risk Management! and soon to come is part 3 - Closing.

Risk Management at the Source - Part 1: Initiating and Planning

2014-04-09T14:04:00.004+03:00

Have you ever came across one of those Risk Management courses that endlessly talk about probabilities, impact, mitigation strategies and the process of assessing risks and putting them in a risk log? Although not a brainer, this approach on Risk Management transforms it in a academic exercise, which explains why in many projects RM is performed only when an audit is around the corner and you need some paperwork to prove you're doing an outstanding Project Management job.

When in fact, even without this paperwork, you are doing an outstanding Project Management job. Because most of our Project Management activities are about managing risks, maybe not as explicitly as if they were listed in a Risk Log. After acquiring some Project Management experience, most of us PMs learn some risks are more likely to happen then other, are able to foresee future problems from current symptoms, and conduct our PM activities mostly around mitigating and minimizing those risks.

So why not recognize this phenomena and create a new approach on Risk Management? A Risk Management that is in the center of Project Management activities, that is real, practical and common sense. Just like Quality at the Source is about embedding Quality at every step of the production, Risk Management is embedded in all project management activities. With this new approach, we want to see a Risk Management perspective on every activity a Project Manager does rather then having an isolated process called Risk Management. Just as in the project lifecycle, we propose:

an Initiating and Planning phase with a Risk Management perspective
a Monitoring and Controlling phase with a Risk Management perspective
a Closing risks phase with a Risk Management perspective

(simplification as compared to the PMI project lifecycle is intentional).

I have listed below some techniques for embedding Risk Management in the Initiating and Planning activities. More posts will follow for Monitoring and Controlling and Closing. Again we talk IT (but most of our projects today touch IT so it became a familiar domain for most of us):

Delivery Method: If you include in your method tasks such as early prototyping, iterations and workshops with the client, you are already planning for mitigating risks such as heavy re-work in the late phases of the project or users not accepting your solution;
Constraints and Assumptions in the offer/contract/Project Management Plan. Constraints and assumptions should refer to limits of what you can do and under which circumstances. These contain the knowledge of the past, of things you know can go wrong or misunderstandings that explode the budget. Have this list updated at the end of each project and don't name it "Lessons learnt" or in any other fancy terms; just a bullet list with assumptions and constraints to be added in the next proposal. List them on components, so you can easily extract what applies on the next project (e.g. hardware, communication, custom development, application implementation, data migration, Business Intelligence, training);
Kick-off presentation. Include in your kick-off presentation to the client a summary of the scope of work, including out-of-scope. This will address the risk of scope creep as the audience will be told early on what is and what is not in the scope of work.
Communication: Instead of presenting your list of risks to the client, throw a "Risk Assessment Workshop" together with your client. If you hear their concerns, it would be easier for your concerns to be heard.
Project Management Method: Include an Acceptance Methodology in the offer/contract/Project Management Plan that contains chapters for each deliverable type (e.g. different methodology for documents, application, data migration, training, hardware, networking services, etc). This of course will save you time and energy in the future if people have different expectancies regarding what acceptance is;
Include default acceptance that will allow you to handle non-responsive clients and move the project forward;
Plan for acceptance criteria that are not absolute in the case of software application. Software will never be bug-free and often it is more valuable to go-live with known issues rather then wait for the application to be perfect. You can phrase it like this: "The application will be considered accepted and ready for go-live if, following the UAT, there are no Severity 1 bugs, 4 or less Severity 2 bugs and there is an agreed plan, with deadlines, for solving all open bugs. ". Then list what Severity 1, 2 and 3 means. With this simple phrase you've just mitigated delays and negative cashflow risks;
Training and communication. Perform orientation and create an orientation communication package for the team, own and customer. This will address the Project Team not knowing where the project is heading or customer staff not understanding their role in the project;
Scope Management. Include a Change Control method in the offer/contract/Project Management Plan. We've discussed here that Change Control is not for rejecting change; still the absence of the mechanism invites to scope creep;
Project Governance. Establish the Project Governance structure, with layers and rules for reporting or escalating, explaining how risks will be brought up and escalated. This will address the risk of slow decision making, the risk of lack of resources and the risk of hurting the feelings of the people being escalated if they know from the beginning this mechanism with clear rules is in place (never underestimate the cost of hurt feelings :) );
Communication again, Staff Management. Explain to everyone in the team that you expect them to communicate any perceived risks and issues, including "Project Management risks and issues" such as scope creep. This ensures your team feels empowered to communicate and to give you hints you might miss;
Staff Management, Work Management. Create a staff plan for resources required from your client and hand it to them before the project starts. Include it in the offer/contract/Project Management Plan. This will address unrealistic expectations and lack of resources from the customer.

I would be happy to hear from you whether Risk Management sounds less abstract now and more like common sense. Posts on Monitoring and Controlling and Closing will follow.

PMO – Standard Operating Procedures

2012-12-18T18:44:00.000+02:00

In addition to the Project Management methodology, the PMO needs a set of policies and procedures for proper functioning. I call these the PMO's Standard Operating Procedures (PMSOP). The difference between these policies and procedures and the methodology is of scope: the methodology refers to one project, while the standard operating procedures are covering all projects and the relationship between the PMO and the rest of the organization, as described below:

Standard operating procedures and the project management methodology

In addition, the policies and procedures customize a methodology that can be too general to the particularities of the organization which owns the PMO, defining the various roles involved in decision-making processes, the tools used and the timing of activities. A set of such processes and procedures, without claiming to be exhaustive, is presented below:

The transition process from business case or offer to project execution – when the project is entering the PMO. If the bidding process or the elaboration of the business case does not happen in the PMO, then you need a clear procedure for the Project Manager assigned to the project to acquire all the information and artifacts that have been defined. If the Project Manager was not involved in the construction of the project, it is quite likely that there will be differences of opinion between the originally proposed approach and the vision of the Project Manager who will implement the project. The Project Manager will identify and attempt to correct the problems prior to starting the project, such as clearly defining scope and project objectives and budget re-estimation. Therefore, the recommendation is that the Project Manager should be involved from the phase of the tender or business case, to avoid these changes and differences. It is even recommended that the same Project manager who will implement the project is involved in the construction of the project, but due to lack of predictability that can occur when approving the project, it is difficult to achieve this in practice;

Project Managers recruitment procedure provides assessment criteria to interview people involved in assessing candidates, compensation and benefit scales for different levels of seniority;

Capacity planning procedure for the PMO is based on income forecast for organizations that run projects for external clients, or on the business plan of the year for internal projects;

The procedure for allocating and communicating project managers' allocation within the organization. Strict allocation rules are difficult to define, but I've seen being used these four approaches:

an allocation based on the technical expertise of the Project Manager
- is an approach I do not use because I work for an integrator that has all kinds of solutions in portfolio, that could'nt possibly be all covered by the Project Management department;

an allocation based on business expertise in the beneficiary’s activity
– in my opinion, this is the best approach because only by understanding the business objectives, will the Project Manager be capable to set the correct direction of the project, to support the deliverable to the customer and to determine appropriate corrective actions;

an allocation based on personal relationships between the team and the Project Manager assigned
- although not a very strategic approach, this can also constitute an important factor to the project's success. If a team is already formed and the risk of conflict is low, all forces will be directed towards achieving the project objectives;

an allocation based on availability
- is not good idea in theory but in practice is the most used although the results are often disastrous. A competitive business environment that does not allow for spare capacity often forces the PMO managers to make such decisions. Therefore, it is important for the project managers to quickly adapt to different project domains: to have a solid technical base, to understand business administration and to quickly catch the specificity of the client. The management style of the Project Manager must also be flexible, in order to allow them and work with diverse people and adapt their management style on different personalities. Project managers with all these qualities are obviously hard to find and very expensive.

The procedure for reviewing and approving the budget and project deadlines in PMO - which would bring accountability to the Project Manager assigned to the budget and time limits. As explained above, if the project was approved following a business case that includes project objectives and a budget and time allocated, it is likely that a newly appointed Project Manager will not fully agree with how the project was initiated. In theory, the project manager has the right to review all these premises and to require a new baseline, usually with a larger budget and / or a longer time, fundamenting the requirement. This is the condition for a Project Manager to be 100% convinced that the project can be successful. In practice, the pressures to fit in the originally approved budget and time will be huge. The project may come from an offer already accepted by the client, which can not be withdrawn and was created to fit into what the customer finds to be reasonable. Therefore, this procedure is often reduced to a record where the assigned Project Manager states the risks seen in the original premises of the project and try to minimize them from the beginning. From this point of view, even the simplified version of the procedure is extremely valuable. It is therefore important that the Project Manager, although he is always put in a position to solve some problems he didn’t cause, to realize that this is one of the reasons why we need project management; it is their art that is needed to lead to a successful project despite initial difficulties.

The revision of the applicable Project Management methodology - we call this the tailoring of the Methodology. This review must occur every time with the initialization of a project. It is then when the Project Manager decides what parts of the methodology applies to a project, considering its size specificity, taking into consideration lessons learnt from other projects and deciding the lifecycle of the project, in the same way that the driver imagines a mental driving route after consulting a map;

The revision of the project scope and its completion criteria - this review must occur every time a project is initialized. This activity is closely linked to the bullet above: it is possible that the objectives are not clear enough, or it is unclear where the project stops, what is and what is not part of the project. This is where the Project Manager, using techniques such as Work Breakdown Structure helps the beneficiary to limit scope. A word of caution: this activity is often viewed with suspicion by the Beneficiary as an attempt to deny what it was originally "given" in the business case, so it is very important to explain that it is in the interest of the project to allow the team to focus on what is important and to be sure goals are achieved;

The initialization of the project in the Project Management Information System (PMIS) is highly dependent on the internal systems in the organization;

The procedure for quality audit which is usually included in the Project Management Plan;

Financial policies for:

revenue recognition;
method for the calculation of the percentage of completeness (point of completion) - with direct impact on revenue recognition;
method for revenue forecast;
an allocation of revenue among multiple profit centers;
management of budget changes;
a reporting calendar.

The procedure for entering timesheets for the project. It is very important that team members enter timesheets daily or weekly. This is difficult to achieve if the company is facing operational overload, because people leave timesheets at the end of the month as a formality for the payment of wages;

Work at risk policy, or how to manage the situations when work starts before the contract or the delivery order is signed. The company will have a policy that states to what extent it can allocate resources without a firm order, if some form of a written document from the customer is required (eg a requirement to start work on the email) and to what level of expense (ie no more than 100 man/days). This policy may also contain conditions for client screening, e.g. if the client is recognized to be a client with a previous good work relationship. A special approval chain for such situations is usually stated;

Procedure for reporting project progress;

Portfolio analysis procedure;

Standard work plan structure, that include activities that are often forgotten, such as activities under the responsibility of the Beneficiary, change management activities or regular meetings;

Risk assessment procedure, that includes practices used elaborate the risk log, to such as: brainstorming with the whole team, brainstorming with the customer for a complete picture;

The procedure for obtaining the necessary human resources for a project, their identification and contracting;

The procedure for the procurement of goods required for the project;

The procedure for closing the project and releasing resources;

Documenting lessons learned and their dissemination in the company, the decision to include lessons learned in project methodology, since Project management Methodology should contain the result of those practices that have already met with problems and specificities of various projects.

Project Management as a company-wide practice

2012-11-27T18:49:00.000+02:00

I have often encountered the situation when Project Management is seen as a Project Manager's solely area of expertise. People let Project Managers do their own mambo jambo, academic plans and presentations, while they continue working in exactly the same way as they did before they worked in a projectized organization.

The first obvious difference is at the team member level. They will not only have two "bosses", but they will need to start reporting in project management concepts:

how long will it take for a specific activity to be completed (estimation)
what progress has been made on the current activities and when they will finish (time to completion)
if there is a deviation from the estimation, what actions can be pursued to correct it (financial management)
what risks and problems are foreseen at the technical level (risk and problem assessment)
what scope deviations are foreseen at their own level (scope management)
what technical arguments can be given to persuade the client to chose a certain solution or to understand scope deviation (client management).

Staff in companies that are young from the project management perspective try to resist providing all these information to the Project Manager. They see it as overhead talk. They believe good Project Managers should be able to know all this and do their own stuff without impeding other's work. But what good Project Managers should do is to try to train their team members and make them understand what is required from them in order for the project to work well. The reality is that Project Management does not work if only the Project Manager practices Project Management.

The second obvious difference is at the managerial and support level. For the Project Manager, everyone is a resource in their project, and as her ultimate goal is to make the project successful, she sees Management, Accounting, Sales, Purchasing, Logistics as entities that should cooperate for her project's success. Unfortunately, Management, Accounting, Sales, Purchasing and Logistics don't see themselves in the same way. They often have different agendas that no doubt are important, without realizing that failing to cooperate with the Project Manager results in blocking the project and wasting the work of the PM or an entire team, the fury of the client and delays in obtaining the revenue used to pay their own salary in the first place. This is why Project Management is a practice that is to be internalized by the entire organization, no matter the role in the company.

In some of my recent work, I have put a lot of emphasis on developing a Project Management book aimed at managers and executives and I plan to actually transform it in a course. You can find extracts from the book by searching for the tag "Project Management - a managerial approach". The concept of Project Management with a managerial approach is the same as with any discipline taught in MBA (e.g. Macroeconomics with a managerial approach, Accounting with a managerial approach): a discipline with a management perspective that is as technical as needed for a manager to be able to manage specialists and make the most benefits of it. I plan to continue with some articles on Project Management aimed at Accounting, Sales, Purchasing and Logistics.

Acting as a Project Sponsor

2012-11-26T18:42:00.002+02:00

As a senior manager, you will often find yourself in the position to sponsor a project. This either means that you are the beneficiary and the owner of the budget of the project, or that the holder of this budget has invested you to play this role.

Even if an executive manager, the Project Sponsor will get more involved in the project assigned, in order to protect the interests of the project. The level of involvement will depend on the phase the project is, but the involvement must be visible and continuous.

From the inception of the project, the Project Sponsor should be interested that the planning (time, features and budget) is feasible. Their primary interest is to ultimately benefit from the results of the project, which will never happen if the costs and/or timeline are too low compared to the features and quality required.

The Project Sponsor should have a small budget put aside for change requests. Don't assume all tasks will go according to plan. Also, don't add an extra 10% to each activity; have 10% form the entire project put aside as a bulk sum that can be allocate in different proportions where needed. It might come to the time that the project is blocked at 90% because all budget has been spent and this will be your safe cushion.

The Project Sponsor should also be interested in the team: the level of allocation required, the competencies and the feasibility of these allocations. Securing the right resources from the beneficiary is key in the success of the project, even if you have a powerful and experienced supplier.

The Project Sponsor should be concerned on the approach of the project. The most successful projects are built in small iterations, so that benefits can be gained early and there is flexibility for change should the business change also during the project lifetime.

The Project Sponsor should be concerned about progress reporting. They should ask, if not already given, for progress information and status meetings from the Project Manager.

The Project Sponsor should be concerned about escalation and establish clear rules when issues should be escalated to her. I have found that Project Sponsors regretted less if issues were escalated to them too early, and more if issues were escalated to them too late: with a phone call, they were able to solve a problem the PM was struggling with for two days. So as a Project Sponsor, keep an open door for the Project Manager or any Team Member and don't frown even if you feel they escalated to early: it might be because they knew you would be able to solve it in less then 1/10 the time they would take.

The Project Sponsor should take Organizational Change and coping with Organizational Change as their task, since it does not only requires skills that the PM might have but also authority that the PM probably does not have.

And finally, the Project Sponsor should be concerned with maintenance: what to do to maintain the solution, the change, the benefits. This is especially important for the Beneficiary organization, because the project was created in order to improve an aspect of how the business runs in the Beneficiary organization. In addition to the tangible deliverables of the project, the Project Sponsor must ensure that the employees use that deliverables and benefit from them. If change that comes as a result of the project is not maintained, the way the company’s journey will look like the graphic below, where each improvement initially brings visible progress, but after a while, the organization returns to its former level, which is the level of comfort of its employees:

Instead, we want to see progress as shown below, so it is important to endorse the level of change after the project:

If we were to use a Pareto analysis, we can appreciate that the effort required to maintain the change is only 20%, compared to 80% effort required to get the initial momentum. It is therefore very unfortunate that this effort is wasted in many organizations who rush to celebrate the success of the project and then forget about it and its results. Some simple ways to ensure that change is sustainable are listed below:

Make changes in small steps, and avoid too much change or change of different areas at the same time, because that would confuse employees;
Even before the end of the project, give great attention to training and communication of project results towards those who will benefit from them;
Change internal rules and procedures so as to include project results in them (for example, when launching a new information system, the job description of the operator must be updated to include the ability to operate correctly and to date in the information system);
Change compensation and benefits packages in order to encourage the use of project results (e.g. at the launch of a new banking product, sales force objectives include a sales target for that product);
Install a post-production support system for those who want to use the project results, but have difficulties - for example a sales person who has participated in defining the product will be available anytime for his colleagues for questions about the product;
Regular audit (announced!) of the change that imposes coercive measures and sanctions for those who do not comply with the measures imposed. It is always advised to use positive motivation, but the truth is that without a set of consequences, employees will be tempted to return to their old way too easily, because this is their level of comfort.

X, Y Motivational Theory and Project Management

2012-11-21T19:07:00.002+02:00

I had recently had a number of conversations with different people on the motivation theory of X and Y. Basically, this theory says that there are two motivational approaches managers have: one that assumes people are inherently bad and lazy and need to be managed by fear (X managers); and one that assumes people are inherently driven by good intentions and find satisfaction in working and having results (Y managers). This is an empirical theory, that is not proven scientifically, therefore I can afford to suggest an extension to it. The fact that managers seem to take either one approach or the other can be easily observed in every organization. Based on my observations, what I suggest is that:

1. The theory is self-enforcing; that is: if one manager treats people as bad and lazy and uses fear to "manage" them, people tend to act as expected, by being bad or lazy, at least when it comes to interacting with the said manager.

2. The X management style is not working in the IT field (maybe neither in some other creative fields or professional services fields). I perceive IT people as highly educated, highly paid, self-aware people that have strong values and self respect. When confronted with an X manager, they will willingly leave the company or (worse) stay and perform poorly until they can find a better job.

These two assertions have multiple consequences in Project Management, because as the definition of the project states, the project is "a unique endeavor", by unique meaning that an assigned project team has to be creative enough to find a path from specifications to the finished product. It also means budget or timeline are not necessarily accurate, which presses for even more creativity and involvement into finding solutions and taking the extra-work necessary for the project success. My opinion is that creativity and extra (productive) work don't go well with X, they can only be found in the Y managed teams.

I am a fan of the Y theory mainly because I genuinely find people interesting and I like to treat them with respect. I also try to be objective enough to understand the weaknesses of such an approach. When people happen to have different agendas or are not productive at work because they use their energy on something else, they find it easier to do this under the governance of an Y manager. The art here is to capture such deviations and intervene with assertiveness (by openly discussing and exposing the problem). Still, I believe that if someone is not correcting their behavior after such a talk, there is very little use to try and force them into the desired change (e.g. by changing managing approach to X). This would be like resisting reality, e.g. that the other person does not feel like working on the same agenda as you do (more on Resisting resistance here: http://www.stevepavlina.com/blog/2012/09/dealing-with-others-insecurities/).

So while I address the weaknesses, I still use the Y approach and I can confirm I have better results then colleagues that use an X approach.

Agile Application Implementation (AAI)

2012-09-21T21:46:00.000+03:00

So I am an IT Project Manager and a huge fan of Agile. I made it a must to try Agile for application implementation and with time I gathered a mix of techniques that really work and I would like to share with the PM community.

Application Implementation refer to installing, configuring and maybe customizing an existing software product (or application); such as an ERP or a Document Management application.

Most of the outdated methodologies around advice to first run an analysis where you capture all the requirements of the users, then you design the solution, then you implement it and then you test it. You know the drill. This is what I call a Requirements Driven approach: you try to map an application to the needs of a customer. Considering that the application has already been developed to fit the requirements imagined by its producers, this approach seems like a bit of a nonsense to me. Nor does it work in practice, and I've seen many colleagues Project Managers struggling desperately to fix the problems this approach brings. And what it does is induce heavy customizations and all the risks associated with custom development: uncertainties regarding effort estimations, lack of flexibility to changes in the business processes and a prolonged testing process that requires a team of professional testers before the application can be handed to the key users for User Acceptance Testing.

I use a different approach that they call an Application-Driven approach that is derived from Agile and DSDM (Dynamic Systems Development Method). As opposed to a Requirements-Driven approach, where the project starts with documenting the requirements and then the application is customized to answer the requirements, the Application-Driven approach is based on using a Gap Analysis technique rather then a holistic analysis. So the first step is to show the application as is and document only the gaps. This leads to minimizing the customizations and using the standard functionalities of the application (yes, it is that simple). This approach has the following benefits:

• Decreases the Total Cost of Ownership (TCO) for the clients since it limits the effort to maintain the customizations;

• Shortens the length of the implementation project;

• Reduces the risks associated with the project by eliminating the risks and uncertainties that are specific to custom development;

• Reduces the effort associated with the project through using development only for integration and light customizations;

• Reduces the length of the future technological upgrade projects (e.g. migrating to a superior version of the implemented product, changing the infrastructure), because there are a limited number of customizations to be ported and retested.

The approach is based on three iterations:

• Vanilla is the first iteration that exposes the users to the application as it is, with only a minimum set of configuration resulted from some initial interviews. The application is presented to the key users during several workshops. The functional consultants document the gaps between the requirements and the application;

• The pilot is the second iteration, with the application configured to answer as many gaps as possible without custom development. This application is again presented to the key users and the key users get to agree on the resolutions of the gaps;

• User Acceptance Testing is the iteration with all the gaps solved, including the ones that require development. The key-users test the application and they give acceptance for go-live.

Although I use iterations, I divide the project into distinct phases, each phase having a purpose and a set of document deliverables resulting from specific activities.

Analysis: The purpose of the analysis Phase is to obtain a unique set of gaps between application and requirements agreed by all parties involved. This is done by exposing the standard application (Vanilla) to the key users during several workshops.

Elaboration: The purpose of the Elaboration Phase is to configure the application to answer as many gaps as possible and to present the configured application to the users.

Construction: The purpose of the Construction Phase is to develop the interfaces and customizations if any, to prepare data for migration and to develop the import interfaces if they are not provided in the standard. I usually import a set of test data to have it ready for the UAT and also to decrease the risk of any surprises during import for production.

Transition: The purpose of the Transition Phase is to run the User Acceptance Testing, to provide the training for the key users and to prepare the system for the go-live. Also, I run an import test on the entire set of data needed for production. Then I prepare the production environment: install, configure and import production data.

Production: The purpose of the Production Phase is to prepare the system for the go-live. Some data will need to be imported just before go-live, the old system must be decommissioned and replaced by the new system. Users and access must be granted. I also run some non-transactional tests on the production environment (non-transactional means no saving - so there are no traces left; usually it means going through all functionalities and make sure forms open and user can access all functionalities).

I have listed below the deliverables I typically use for an application implementation.

Analysis	Gap Analysis document - Describes the gaps between the standard application and the requirements of the Client.
Elaboration	Application setup document - Documents the client specific configurations. Gap Analysis (Updated) Documents the solutions for the gaps.
Construction	Technical documentation of the developments - Documents the custom developments (if any) Data Mapping document - It provides the mapping between the source of the data and the future system's tables. UAT Test scenarios - These are the agreed test scenarios that will be used during the UAT.
Transition	UAT Results - Documents the results of the User Acceptance Testing. User manual - Documents the utilization of the application.

Enjoy AAI!

PMO’S Organizational Impact

2012-08-22T19:52:00.003+03:00

The introduction of Project Management and Project Management Office has an organizational impact that should be monitored carefully in order not to adversely affect the company. Many effects are not seen in the early months after create structure, but appear after some time of running. The most common problems are:

• The exponential growth in the number of staff from the PMO: As it operates, the organization is transferring more and more work within the PMO, considering that this will raise even more the benefits it provides. Top-management, that can now trust the new structure, will address to the PMO for convenience, instead of requiring that work should be carried out within departments. This is not always beneficial; for acquiring real maturity in Project Management, the entire organization should learn to work horizontally and Project Manager should have less work to do, not more;

• Bureaucracy: In an effort to gain control of the department acting as a company within a company, a PMO Manager will create a lot of reports, policies and procedures to force departments to formally give control to the project managers and to enforce double subordination. With time, these rigid papers should be replaced of communication, cooperation, guidelines and a minimum of paper;

• PMO involvement in all activities of the organization: With confidence gained in the PMO, top management will tend to assign all sorts of activities to the PMO, which will lead to a bottleneck of its activity and an overhead of communication unjustified by benefits. In this respect, some limitations should be established PMO activities such as:
- the value of the project;
- project duration;
- involvement of two or more entities (departments, suppliers);
- Risks for a company;
- If the goal is critical to the company (eg a new product launch before the holiday season).

Special attention must be given to cost reduction initiatives. If you want to maintain the for the PMO medium and long term, do not declare such an initiative as a project for the PMO. Resistance to a measure to reduce costs will be added to the resistance to the new way of working and will compromise the PMO and the definition of Project Management. Rather, approach this initiative as a target for each department manager to reduce costs in his department and for the PMO to improve inter-departmental processes to achieve synergy.

On the other hand, with the establishment of PMO, executives and managers should quickly find the following qualitative benefits:

• The number of conflicts and problems escalated at your level dropped because it was filtered and settled largely at the Project Managers level;

• The time required for finding information on the progress of a project decreased. Without PMO, the information on the projects are scattered throughout the organization and there are multiple formats for planning. With the standardization brought by the PMO, status meetings are shorter and more revealing;

• Decisions on strategic initiatives are difficult to take in the absence of a PMO and are often delayed. With a PMO, data are available and decisions are possible.

• Time spent in meetings is shorter when there is a contact point that has for information, knows the issues and know who and in what meetings should be involved. As executives, you have the opportunity to spend less time solving operational problems and more time in strategic meetings.

On Project Management Office

2012-08-20T16:35:00.000+03:00

I am on vacation, so I will be blogging a lot :).

Today it's on Project Management Office. We will discuss in later posts about its impact in the organization and the Project Management Information System.

The concept of Project Management Office was introduced in this post as a structure that is established when a company reaches a certain level of maturity in terms of Project Management. PMO can be established even earlier by a visionary executive management, but then the journey of this structure will be longer and more difficult, until the organization matures to allow for proper functioning of the PMO.

What does actually mean a Project Management Office? The meaning of the PMO might vary, according to senior management vision who needs to define and explain the objectives of the PMO to the rest of the organization. An example of the mantra of the PMO is described below.

The role of the Project Management Office is to supervise all activities of Project Management and to ensure standardization and predictability in how projects are run. Standardization is ensured through the use of a single project management methodology, and predictability is ensured through regular operational processes such as: Revenue Forecast, Progress Reporting and Portfolio Analysis.
In terms of the PMO and project managers, departmental lines are transparent and decisions are related to the whole portfolio, rather than at the department. For senior management, PMO provides the information necessary for optimal planning of resources, especially human resources, and access to any information required on the project. PMO is the single point of accountability on projects in the portfolio.

We underlined in the above description the word "predictability", which is very closely related to standardization. These are key words in a company, because they provide control over the future of the company. The stock exchange or the investors appreciate the quantitative indicators (eg, income or profit), but also the predictability of a company's financial statements as compared to the forecast. Any variation is perceived as a risk to the company's shares of stock in question and is penalized by a decrease in share price (for more information see the course of "Investments").

How is this linked to project predictability? In the case of organizations delivering services and solutions customized in a B2B model (business 2 business), projects provide the vast majority of revenue and profit. It is clear then that their financial results are as predictable as the Project Management activity, depending on delivering and billing projects as expected.
If organizations are not project-oriented, the projects are actually initiatives to create new products or make changes (improvements). In any case, the ability to run successful projects and completing projects on time is the company's ability to keep up with competition, market and industry. The relationship between healthy projects and financial results is more subtle and it is more difficult to demonstrate an impact on profit for example. It is therefore important to look at projects’ Return on Investment (ROI), and to determine the opportunity cost in case of failures or delays, to motivate management to provide resources to projects.

Planning for change with Agile

2012-07-13T15:13:00.000+03:00

Change is inevitable during projects. Many Project Managers, and Customers, wrongly interpret scope and change control procedure as methods of limiting the change, when can actually be tools to facilitate change, while maintaining control over the project. The change control plan is developed since the startup of the project and it is a good idea to communicate with the client at the kick-off meeting how change will be addressed during the project.

During project implementation, priorities change, new elements can occur that during the analysis were omitted, that are implicit requirements or that no one thought of. If you choose to implement using an iterative method (e.g. Agile), which implies presenting periodically the application / product to the client, changes will occur earlier. If the approach is sequential, meaning to show the client only the end result, these changes will be deferred until final acceptance, which increases the risk of the project. In an iterative approach, the client sees an intermediate product and is able to work with it (even for testing purposes), so they can tell when some functionality was forgotten.

As change is inevitable (many say it is even recommended) under the pressure of the business environment today, which is in constant motion, why is Project Management sticking to the old, un-flexible way of doing business? Why not admit that change will happen and plan for it ? What can be done about it?

First, consider how being unflexible about change might cause tensions with the client. And we can identify two cases:

• The client failed to include important functionality but allocated all budget. They want the missing functionality to be included, or the system will not be useful for them, but the zero budget constraint blocks any change;

• The review of the project scope has "grey" areas that lead to interpretation.

One solution in such cases is to introduce the new requirements and remove the less important features not yet implemented, so that efforts to implement the new functionality will be equal to the ones out. This means to have (or will have to create) a list of product functionality, ranked by their importance. It will be much easier for the customer to decide what features can be removed, starting with the end of the list. This is called a MOSCOW list in Agile. Agile can help with spotting implicit requirements as well, early in the project, by exposing the customer to the product in early stages of the project, so that the client can pin-point if something important is forgotten.

Another important method by which we can prepare for change is to advise the client that they keep a part of the budget for the times when extremely important features are found but were not expressed in the initial scope. A good rule of thumb is to have this contingency at about 10% of the project. This will create a comfort for the project team from both the client and the provider that there is a solution for crisis situations and the whole team will focus on achieving all project objectives and carefully using this contingency, and not searching for ways to defend their position. In my experience, fully allocated budget with the assumption that everything will go according to plan ranks among top 5 reasons for project failure. That is why, when in a project that is in difficulty, I always advise the client to budget 10-20% for change requests. It is not a lot, after all the work and the struggle of the project, and lifts a lot of tension from both the client and the provider, leading to a normal working environment and quality results.

Finally, a Project Manager should introduce these mechanisms at the proper time. The easiest method is to discuss this possibility with customers early in the project, namely during the kick-off meeting, or even earlier if possible.

Set expectations from the Steering Committee

2012-06-22T17:42:00.000+03:00

Handling Steering Committees requires managing up, which is why it is very important to communicate your expectations and obtain commitment from the senior executives that they would act as such. In order to make the Steering Committee an escalation mechanism that works, present these simple rules and obtain agreement on them:

1. Issues that are escalated to the Steering Committee are:

Discussed with the Project Management Team and a solution has been attempted;
Not within the Project Management Team power;
Resulted from private agreements and discussions that the Project Management Team has not attended;
Important effort/time can be saved if escalated early.

2. What each member of the Steering Committee should do with regards to problems:

Brainstorm for solutions, contacts or resources;
Make decisions or take actions to solve problems ("make that phone call");
Assume responsibility and get involved.

3. What the SC is not:

a wall that bounce back problems to the project team: issues should result in a resolution;
a place to "shoot the messenger";
a place to make the Project Manager an "escape goat".

Since Steering Committees are about managing up, and practically all initiatives in corporations are projects, these rules can be used also to govern any escalation mechanism, board or committee. Find here the slides for such a presentation; you can use them for the kick-off meeting for instance.

A word on Steering Committees for project in crisis: If your project is in crisis (or you have assigned a red flag to it due to its many risks), proper and often function of the Steering Committee is vital. Make sure to establish the Governance Mechanism using this post I've wrote, but make the frequency to be at once a week (that's right, 1 time per week), and note that for project in crisis, it's critical to escalate issues early. So paragraph number 1 becomes:

1. Issues that are escalated to the Steering Committee are:

Important effort/time can be saved if escalated early. (nothing else matters)

It is also critical that a senior manager gets involved on a daily basis, and so paragraph number 2 becomes:

2. What each member of the Steering Committee should do with regards to problems:

Get involved, assign at least 1 senior member to get involve daily.

How the Executive Management Should Get Involved in Project Management

2012-05-09T19:30:00.000+03:00

Why is it difficult for organizations to move ahead towards implementation of professional project management processes? For some of the following reasons:

Project management appears to involve the shifting of the poles of power, taking power from functional managers and giving power to the Project Manager (this is only partially true, since functional managers will actually be the first to benefit from Project Management);
Project management involves horizontal control with regards to the financial implications and on how each team member carries out his work on the project. Success of the project is the responsibility of Project Manager, and therefore lack of performance can not go unnoticed;
Project management involves what may be perceived as an overhead devoted to planning, reporting, financial accounting, etc. This effort cannot be done by the Project Manager alone, but only together with the team. This leads to frustrations that Project Management is actually an increase in overhead and bureaucratization.

Therefore, executive management involvement in the above levels of maturity is required in order to achieve the acceptance of the organization for the objectives and processes for Project Management.

Executive management must visibly support actions to establish concepts of Project Management in the organization, or the other employees will think the higher management is not convinced of the necessity of this action, the functional managers will be reluctant to give support to the project managers and the entire process will be hindered. Often, perception is formed even in the executive managers‘ eyes that the Project Management "does not fit with our organization" and the whole process may eventually be abandoned.

But why is it important for executive managers to implement project management processes? In organizations where the concept of Project Management function effectively, the role of Executive Manager change. Initially, the executive managers were involved in carrying out everyday projects, especially in terms of initiatives or strategic customers. But as project management matures, executives get a more passive role, allowing them to focus on what should really be their job: planning and long-term strategy. As they gain confidence in the Project managers, executive managers increasingly rely more on them for daily decisions and consider Project Management has a fundamental role in ensuring the success of their organization.

In conclusion, a mature organization in terms of Project Management is manifested by:

Understanding Project Management's benefits up to the Executive role;
Continuous and visible support from senior managers for Project Management;
A desire from senior managers not to get involved in the daily activity details and to rely on Project Managers to provide high-level information relevant to them.

Project Management Maturity

2012-05-05T12:09:00.004+03:00

The model of Project Management Maturity consists of five levels, although it is often found that these levels overlap and there is no clear borderline between them. They are listed below and will be detailed in the next subchapters.

Levels of Project Management Maturity

1. Intuitive Project Management

In this organization, the Project Manager is not yet recognized as a distinct professional. The initiatives are run as projects in an intuitive fashion by the most enthusiastic team member. This team member has a strong desire to succeed and self-appoints as being the one responsible for the project (this is how a Project Manager is born). This leader will use some empirical planning techniques and sometimes bypass the planning all together because everyone is looking for seeing some “real work” done and some quick wins. It is unfortunately to find that of the initiatives run in this fashion will die out, especially when they are run for an internal client, or will have difficulties in reaching the completion point. This is due because nobody takes the time to initially define in a clear fashion which should be the end result.

However, there is an advantage to this approach. This type of Project running will not provoke resistance from the hierarchical organization, because the project team and its leader will be usually located inside of the same department. Working as a project team is natural and there is no need for an organizational culture shift in order for the project to be managed.

For the organization to jump at the next level, the top management needs to recognize the Project Manager as a stand-alone profession and prepare some training for the project teams that will facilitate understanding how the projects should be run. The most frequent reactions to this jump are coming from the team members and functional managers, and will most likely sound like this: “Formal Project Management does not apply to us” or “We are doing fine without it”. On the other hand, executive managers will know this organization favors silo-decision-making: decisions being at the department level, that are good for that department but are not optimal for the organization as a whole. This organization will make interdepartmental initiatives’ fail out of lack of authority and organizational change will be impossible.

2. Acknowledged Project Management

After a few failures of the strategic initiatives and seeing the inability of the isolated departmental teams to induce change on a organizational scale, the senior management will look for a virtual team that comprises members from all departments that are targeted by the project. They will also look for a single point of contact, responsibility and information. The Project Manager title will naturally emerge, very often as an extra-hat next to the functional title. Team members will now report to multiple bosses, which will cause the first reactions of resistance, like some sort of indiscipline for the work related to the project. This makes communicating of the first successes very important: they can be about cost reduction, shorter implementation timeframe for the same quality and scope, or an increase of customer satisfaction. This is the point when senior managers should ensure there is a continuous flow of projects and look for best practices and lessons learnt being applied in the next projects running.

As costs distribution on projects becomes necessary, the accounting system needs changes to accommodate this requirement. It becomes visible where money is spent without justification, and pressure is put that not only should projects be successful and in time, but that they should be cost effective too. A lot of company cannot jump above this level because of the inner resistance to controlling costs in projects (horizontal accounting).

3. Project Management Methodology

Acknowledging Project Management as a stand-alone profession is a huge step, but projects will be run in a more or less successful fashion until some crisis strikes that requires the superior management’s attention. This is the point when top management should require documentation on how should ideally a project be run. This documentation should comprise of a standard activity list, best practices and Project Management deliverables that will make the success of the project less dependent on the Project Manager’s experience. They will also require a procedure for escalating risks and issues to the upper management levels if this is the case, which will enable corrective actions in a timely fashion. This is how a Project Management Methodology is born. The methodology can be adopted, adapted or unique, as the organization requires.

This phase comprises the greatest risk for the Maturity in Project Management pathway. It means a major shift in organizational culture and the resistance can be huge, varying from skepticism to nearly sabotage. Top management must show constant support for the Project Management concept during these times. Once this resistance is overcome, the two levels that come will be more natural and less risky. The problems that might be encountered during this phase are typical for any organizational change:

ü Conflicts caused by changes in power and authority balance – that is, the Project Manager is seen as getting too much influence and stealing power from functional managers;

ü Working horizontally and reporting to multiple bosses is not accepted by team members;

ü People might hind behind current procedures and politics in order to justify lack of initiative and extra effort;

ü Time is wasted in meetings for conflict resolution, aligning conflictual objectives and point of views and useless reporting to managers who would feel comfortable to delegate authority;

ü People might use e-mails and other forms of documentation to hide and pass on responsibility;

ü People might fight for resources;

ü People might experience a low level of motivation.

In order to advance from this stage, the management must institute the culture that the methodology is not a rigid set of papers. In mature organizations, the methodology is supported by the entire organization and individual behavior is determined by the philosophy of the methodology adopted. The methodology is not used as an excuse and all members of the organization participate with extra effort if there are problems. Achieving this kind of thinking is especially difficult in fragmented organizations, with different subcultures, which are required to convert their local thinking into a unified and cooperative approach. Culture must be nurturing, based on communication and collaboration, and is therefore important to establish the correct relationship between the Project Manager and rest of the organization:

ü Project managers and functional managers are equally responsible for the successful completion of the project. Functional managers need to keep their promises to project managers regarding resources, efforts and deadlines;

ü The Project Manager title is a recognized as a stand-alone profession. The Project Manager is no longer the functional manager or the best of the technical people.

ü Project managers negotiate with functional managers project deliverables, not people allocated. It is the functional manager’s ultimate decision to allocate the right people in the context of other business constraints;

ü Functional managers trust Project managers enough to give them authority over the team and not to intervene in the way the team is run;

ü If a functional manager can not achieve the objectives assumed, the Project Manager has the duty to persuade him to seek alternative solutions;

ü The Project Manager has the authority to make decisions regarding the project he leads. Decision-making authority and power are decentralized;

ü The Project Manager is required to inform the project sponsor and ask them for intervention if required. At the same time, the project sponsor will be permanently available to help, but it will not interfere in the management of the project and will not take decisions in project matters;

ü The Project Manager (and other team members) are encouraged to submit recommendations, alternatives and ask for allocation of resources outside the team and even from the senior management team, if this is required to solve problems beyond its authority and in the best interest of the project. These recommendations and requests should be included in an internal project progress report. What you need to include an internal report of progress has been explained in Chapter 13.3 Project progress reporting;

ü There is a process of internal progress reporting that runs periodically (chapter 13.3 Project progress reporting).

The organization has reached the maturity needed to reach the next level when it recognizes the difference between project management and operational management, and that a different set of skills is required to act as Project Manager. The focus moves on:

ü Motivate Project Managers to be more proficient;

ü Recruitment / growth of Project Managers who excel;

ü Increased productivity of the project team;

ü Increased productivity of the organization as a whole;

ü Establish project methodology as a current practice.

Achieving this level of maturity does not mean that running totally/only successful projects. It means that they will be run efficiently, thereby maximizing their chances to be successful. Indeed, by measuring number successful projects, top management should be able to see an upward trend. But project management, even at its peak performance, does not solve problems of unrealistic goals or unfavorable economic or organizational context.

This author empirically considers that this phase, from its initiation until the maturity necessary to move to the next level, might take two years.

4. Project Performance Benchmarking

The organization that reached this phase will put a lot of emphasis on measuring project performance and project portfolio performance. Besides the quality of the portfolio can be measured, other aspects can be measure, such as the accuracy of the initial planning, financial forecast accuracy, risk management accuracy, customer satisfaction, quality of deliverables, etc.

This is the best time to establish a Project Management Office (PMO), or a Community of Practice in Project Management. The difference between the two is mainly about the power of the new structure, the subordination of Project Managers and the list of responsibilities of each form of organization. With a Project Management Office, Project Managers report to the Director PMO, while the Community is a virtual structure having a professional leader, but the Project Managers remain subordinate hierarchical, to the functional manager.

The difference of functions within each structure is shown below. One can see how PMO’s responsibilities include excellence in Project Management that is provided by a Project Management Community and receives additional functional responsibilities of being the central point and health monitoring project costs (Portfolio Management, post to follow).

This is also the time when, in order to meet the need for measuring performance of project management activities, dedicated Project Management Information Systems (PMIS) are implemented in an organization.

Some resistance to change can occur in this phase. The measurements made can be dismissed as erroneous, due to some conjectural factors, and even the original authors of the methodology can withstand measurement initiatives for fear that the results could be bad and can block improvement initiatives, using arguments such as "Measurement is not relevant to us" or "It does not apply to us."

5. Continuos improvement

Based on the understanding provided by performance measurement of the projects, the necessary corrective measures can be taken to improve the quality of project management processes. Another objective may be to simplify the methodology and minimize required documentation once the organizational culture was transformed. In this phase, the top management should encourage useful documentation project, clear and efficient communication, minimize emotional conflict, and document lessons learned and improvements to make them available for the next project.

This is when a personal development strategy is created for the Project Manager, with mapping between levels of seniority of Project Managers and relevant curriculum for them.

Also, the organization may become interested not only in comparing projects with their own objectives, but also with how other organizations are implementing Project Management, their cost structure and the improvements they make.

As Project Managers themselves become seniors, and the organization gains confidence that the processes of project management is functional, rigid policies and procedures are abandoned and replaced with guidelines, checklists and reusable artifacts. Both the organization and the Project Manager can enjoy more flexibility, an informal style based on collaboration and cooperation, rather than enforcement. Unfortunately, this goal can be achieved only at the fifth maturity level, because only then can the project management function effectively and without the rigid controls imposed by the policies and procedures. There is o shortcut: all large organizations go through the control phase before they can reach an informal style of Project Management. Even at this level, the senior management must question periodically whether by undertaking informal Project Management, the company does not return to lower levels of maturity, and to balance the need to control with the informal style in order for the Project Management to remain effective.

Guerilla Project Management for Executive Managers

2012-05-05T11:52:00.001+03:00

Why is Project Management important for Executive Managers? Our daily activities and jobs include Project Management activities, even if they are hidden under different names. This blog is partly about how to run projects, and partly (and puts a great emphasis) on how to benefit from a Project oriented approach, no matter which step of your career you are to.

Implementing Project Management, meaning implementing a Project Management methodology, opening Project Manager jobs or creating the Project Management Office, is usually an initiative of the top management of a company, because they are in perpetual search of new ways to develop competitive advantages. That is the rationale for this blog being partly addressed to executives: one must know what to expect and ask from Project Management and where is her organization on the path of Project Management Maturity. You will find what is common and what is not in the problems you might experience during this journey, all with the purpose of being successful in implementing Project Management as a competitive advantage.

Although based on the PMBok methodology, this blog is not destined for studying for the PMP certification. There are far more thorough materials available for this purpose. The best practices (in my opinion) that are described here are exclusively based on real practice and can differ from the theoretical concepts the PMBok describes. They are presented somehow different for ensuring a practical, down-to-earth understanding for people that are not specialized in Project Management.

Here is how to benefit on Project Management no matter where you are:

• If you are an executive manager: use Project-oriented organization in order to achieve you business/strategic objectives;

• If you are a senior manager and work in a company that could benefit from project-oriented approach, use the rationale presented by this blog to see how it can apply to your company and to convince upper management to use a Project Management approach;

• If you are the Project Sponsor, that is, you pay for the project from your own budget, use this blog to find out how to act as a Project Sponsor in order to maximize the benefits for the money you are paying;

• If you are a Project manager that has an internal client (that is, from your own organization), find out how to relate with the rest of the organization in order to secure the resources that are needed for the project;

• If you are a Project manager that has an external client (that is, from outside of your organization), find out what is specific for these projects and how to involve the client for their being successful;

• If you find your self being a de-facto Project Manager (although your title might differ), use this blog to formalize your knowledge in Project Management; it is my belief that each and everyone of us is a Project Manager, either at work or at home.

This blog uses the following concepts as its core:

• Project-oriented organization and approach: its description and why is it considered sound business practice. How to ensure cross-functional and cross-departmental initiatives success by using virtual teams (Project Management Maturity);

• Understanding organizational culture needed to reach certain levels in Project Management Maturity, ensuring the context needed for successfully reaching business objectives using projects and nurturing a culture that facilitates quick decision-making and short communication paths within the organization. How to stimulate initiative, participation and group motivation at all organizational levels (post to follow);

• Understand project definition, the adequate project size and how to allocate a Project Manager that fits the job. Effective management by delegating authority and control to a good Project Manager (post to follow);

• What means a good Project Manager and how/where to recruit the needed Project Manager (post to follow);

• Understand what is a Project Management methodology and what advantages it brings if used consistently. Add a complex practice skillset in general planning and managing projects, and use them to create competitive advantages for your organization (post to follow);

• Understand the project lifecycle: Start-up, Planning, Executing, Controlling and Closing (post to follow);

• Define a program as an interrelated set of projects with common objectives and interdependencies; manage change within your organization that comes with implementing programs. Learn the level of necessary skills required for running big projects/programs and how can one advance from Project Manager to being a Program Manager (Program Management, Program Governance, Managing Change, Communicating Benefits, Choosing the Right Program Manager);

• Understand Portfolio Management concepts and how to analyze a Portfolio of Projects (post to follow);

• How to set up a Project Management Office (post to follow).

Workflows pentru Mac OS Snow Leopard

2011-12-04T08:31:00.009+02:00

Un Guerilla Project Manager e un productivity freak, si la fel sunt si eu. Inspirandu-ma din articolul lui Steve Pavlina Sharpen the Saw, in care Steve Pavlina pledeaza pentru folosirea timpului liber nu doar pentru relaxare ("drop the saw"), dar si pentru a face diverse lucruri ca sa devenim mai productivi ("sharpen the saw"), am folosit o jumatate de zi ca sa studiez posibilitati de automatizare cu Automator-ul din Mac OS. Ca si utilizator de Windows trezit intr-o dimineata buimac in lumea Mac OS (mi-am luat un Macbook Air pentru ca era singurul ultra-portabil de pe piata care era la fel cu minunatul meu Toshiba Portege, pe care l-am dat cand am schimbat jobul si care intre timp nu se mai fabrica), am ajuns in scurt timp sa iubesc Mac OS si sa renunt la ideea de a pune Windows pe Macbook. Dar sunt unele features ale Windows-ului care sunt grozave pentru productivitate si pe care nu le-am regasit in Mac OS, cum ar fi Cut & Paste de fisiere si Send to Mail direct de la clic dreapta pe fisier. Automatorul parea sa fie solutia la aceste probleme.

De asemeni utilizam in Windows Create New Text Document, Create New Word Document, etc, direct dintr-un director. Cautand pe web, se pare ca a existat acum mult timp un utilitar pentru Mac numit NuFile care facea exact asta, dar nu mai este intretinut si nu functioneaza pe Leopard. Dar se poate foarte simplu in Automator.

Asa ca sa le luam pe rand:

In loc de Cut and Paste am facut un worflow foarte simplu pe care l-am numit Move. In automator (se gaseste in Applications), dati new service.

Workflowul este de fapt o succesiune de operatii care se executa ca un script, de aceea ceea ce trebuie sa facem in continuare este sa spunem care sunt acesti pasi. In "Service receives selected" selectati "Files and folders" in "Finder.app". Aceasta arata Automatorului ca serviciul este un plugin pentru Finder si se aplica pe fisiere si directoare. Din stanga, din meniul Actions, alegem "Files and Folders" si actiunea "Get Selected Finder Items". Aceasta spune Automatorului sa ia selectia curenta din Finder si sa o paseze ca valoare pentru actiunea urmatoare. Pentru actiunea urmatoare, tot din meniul "Files and Folders" alegem actiunea "Move Finder Items", unde alegem un director default, de exemplu Documents. Move Finder Items nu e o actiune pe care sa o lasam 100% automata, deoarece vrem sa putem alege destinatia. De aceea, din ultima actiune dam clic pe options si bifam "Show this action when the workflow runs", ca mai jos:

Il salvam cu numele Move. La clic in Finder pe numele unui fisier sau director (merge si pe selectie multipla), se vede actiunea Move, ultima optiune a meniului contextual. Dau clic pe Move si apare fereastra de dialog:

De aici aleg unde sa dau Move.

Nu e la fel ca si Cut & Paste din Windows, dar deocamdata imi pare mult mai util pentru ca nu mai trebuie sa navighezi printre fisiere pana la destinatie si apoi sa revii la calea initiala.

In acelasi mod am creat automatorul "Send to gmail", care arata ca mai jos:

Ce e special la acest automator este ca am folosit o variabila pe care am denumit-o Files, pe care o initializez dupa primul pas cu actiunea "Set Value of Variable" si pe care o folosesc la Subject ca sa includa informatii despre numele attachmentului. De asemeni, foloseste ca si cont de mail contul de gmail (am mai multe), de aceea am botezat automatorul "Send to gmail". In mod asemanator mi-am facut un automator "Send to outlook" pe care il folosesc pentru mailul de serviciu, pentru ca datorita infrastructurii din firma trebuie sa folosesc Outlook pentru Mac pentru mailul de la firma.

Ca si observatie, daca dai Send to gmail pe un director, Automatorul il va zipui si atasa ca arhiva (fara ca eu sa fi precizat asa ceva in Automator). Dragut, nu?

N-o sa mai insist, prezint mai jos restul automatorilor pe care i-am facut:

Create New Text File direct din Finder:

Create New Excel Document direct din Finder:

Create New Word Document din Finder:

Communicating benefits

2011-12-03T19:50:00.011+02:00

An important activity in Program Management is the setting, management and communication of benefits. It is not enough to carry out large-scale activities that lead to real improvements, if such improvements are understood only by a handful of top managers. A Program Manager must lobby for his Program and communicate its benefits, while making sure that all those affected by the program's results see its benefits as such. For example, when launching a new suite of products, although studies show that these products are required by the market, customers will not benefit from them if sellers were not trained and motivated to promote them. Similarly, if the organization does not provide visibility about sales growth after launching these new products, the team who worked on the program and those who were forced to make further efforts to adapt to change will not understand if their efforts mattered. Without this effort on training, communication, follow-up on training and support, the success of the program is seriously endangered, and also the organization's confidence in future initiatives may be undermined. An organization that does not believe in large-scale transformations becomes apathetic and will be quickly surprised by market movements or competition. So, before starting the program, set realistic goals for targeted change. Communicate these objectives (see chapter 12.4 Program Governance), check during the journey that they remain realistic and truly perform the work required on communication. Program Managers use the following techniques for managing and communicating the benefits, and you should make sure the designated Program Manager in your organization uses them:

Communication plan

This plan contains information about the benefits that must be communicated, and to whom. The audience is split in groups affected by the program (stakeholders) based on individual interests. Who needs that information, when (how often), and which is the most effective communication form?

Benefits Register

Similar to the concept of risk register and open problems in Project Management, the Program Management has a Benefits Registry, which lists all the benefits provided, how to touch, how to measure them, the frequency of monitoring and responsible roles in achieving benefits.

Training Plan

To ensure that all concerned benefit from improvements brought by the program, a training strategy is required. Usually, in extensive changes, training is done in several iterations, checking at each iteration the readiness of the employees. For example, in a information system implementation, the users are trained during an intensive program and then they are verify with a test a few days before the entry into production, then the entry into production, users working in the new system in the workshops, together the implementation team.

Transition Plan

Similar to the transition plan in project management, which is the hand-over of complete deliverables to their use in production, in the case of Program Management it is necessary to establish responsibility for maintaining benefits after the program is complete and operational. For example, when implementing an ERP system, before launching it, a support team should be established and a support line communicated, where users can call to request additional information. It is also important to establish a method to promote the new system and nominate champions that will gather additional requirements arising from the use of the system in production.

Support Plan

The inherent difficulties in using the results of a program can be planned and managed through a support plan. This plan should contain information about the location of the new manuals and procedures, who can give information about new procedures, and a way to frequently collect and disseminate the most common issues with how to resolve them.

Managing Benefits Process

Figure above presents the process of benefits management and how the above techniques can be used in the process. The process begins with the formalization and analysis of the benefits. The program was born as a result of targeted benefits, so this step is just to make sure they are formally stated. During analysis, the benefits are prioritized and methods of measurement are established. The Program Manager needs to plan how they will be implemented, monitored and progress communicated. As the objectives are achieved, information is communicated to those interested. At the end of the program, benefits are handed over to operations.

Antreprenor pentru viitor

2011-10-28T18:35:00.004+03:00

Vineri, 21 octombrie si sambata, 22 octombrie am tinut primele 2 seminarii de "Management antreprenorial" din cadrul proiectului Antreprenor pentru viitor, desfasurat din fonduri europene de catre Bucharest School of Management. "Antreprenor pentru viitor" este un proiect pe care in acest moment il vad de mare impact, in care 200 de antreprenori aflati in dificultate au posibilitatea sa intre in contact, sa se instruiasca dupa o curicula in stilul MBA-ului Romano-Canadian, dar mult prescurtata, sa faca un plan de afaceri pe care vor primi feedback de la trainerii MBA-ului si sa obtina o finantare de 10.000 de euro daca se afla printre primele 20 de planuri de afaceri cele mai bune. Si alte planuri de afaceri pot fi considerate viabile si echipa BSM isi propune sa gaseasca "business angels" pentru acestea. Antreprenorii sunt din Bucuresti si Cluj, iar seminariile se fac la fel, in Bucuresti si Cluj.

Am avut cateva mari indoieli cu privire la succesul pe care il vor avea aceste seminarii, care din fericire au fost spulberate de roza realitate. Mi-era teama ca:

1. Antreprenorii din audienta sunt in fapt interesati doar de banii pusi in joc; probabil e adevarat pentru unii dintre ei, dar este si suficient de motivant ca sa traga tare la cursuri, pentru ca isi dau seama ca vor fi evaluati mai bine daca pun in practica ceea ce incercam noi sa predam. Eu mi-am propus sa ramana cu ceva dupa acest seminar de Management Antreprenorial indiferent de rezultatul evaluarii planului de afaceri, si ei au raspuns cu entuziasm, ceea ce a fost o surpriza tare placuta.

2. Antreprenorii nu vor veni la cursuri; de fapt au venit toti si au stat si inainte si dupa ore de vorba cu mine si cu colegii lor, dezbatand diverse probleme si facandu-si unii altora propuneri de afaceri. Chiar si eu am beneficiat in mod suprinzator de acest networking, si mi-am facut cateva contacte care ma vor ajuta foarte tare pe viitor.

3. Antreprenorii vor fi dezinteresati, plictisiti sau blazati de o abordare mai academica asupra mediului de afaceri, ca cea dintr-un curs de management; aici si eu m-am straduit sa vorbesc pe limba lor, sa le insuflu entuziasm si sa ii focalizez pe ceea ce pot ei controla: propria strategie, propria echipa si propriile abilitati. Adesea, frustrarile legate de mediul economic si de afaceri au iesit la suprafata sub forma de "La noi nu se aplica" si "La noi statul ia, nu da"; dar incet, incet am canalizat discutia spre "Poate ar fi mai bine daca as sti taxe sau as consulta un specialist pe taxe" si "Gata, ma inscriu la masterat de drept comercial sau ma duc la un avocat".

4. Eu nu voi avea ceva nou sau util sa le spun acestor oameni. Aici suprizele placute au fost multiple: Au considerat ca am ceva interesant de spus lumii, au invatat si din studiile de caz (romanesti) pregatite cu ajutorul colegului meu Adrian Chindis si au invatat unii de la altii, tot dezbatand si contrazicandu-se. Si eu am invatat de la ei tot felul de lucruri si mi-a placut entuziasmul pe care nu il asteptam de la niste antreprenori in dificultate.

Asadar, despre ce e vorba in cursul asta?

Acest curs are ca obiectiv principal să convingă antreprenorii ca notiunile și abilitățile de baza de management le sunt de ajutor pentru dezvoltarea unei afaceri sustenabile și pentru a face față situațiilor dificile. Iși propune să motiveze antreprenorii să gândească strategic și să planifice mai degrabă decât să exploateze pur și simplu o oportunitate întâlnită.

Acest obiectiv global este atins prin:
- furnizarea tehnicilor si framework-urilor de analiza necesare antreprenorilor pentru identificare oportunităților;
- furnizarea instrumentelor de evaluare pentru a vedea dacă sunt capabili să capitalizeze ideea pe care o au pentru afacerea lor;
- furnizarea instrumentelor de articulare a viziunii, misiunii, valorilor si planului de implementare, cu trimitere catre cursul de „Planificare a afacerii”.

Cursul porneste de la premisa ca ideea afacerii în sine, oricât de inovatoare, este doar o parte (importanta) a unei afaceri de succes, pe langa aceasta fiind necesare si o echipa, o tactica de implementare si abilitati proprii de management antreprenorial. Acestea alcatuiesc fundamentele unei afaceri sustenabile.

Cursul se concentreaza si da exemple din afacerile actuale, de preferinta de pe piata romaneasca, punand in discutie nume cunoscute cum ar fi Blue Air, EBoda sau Mic.ro. Are o componenta puternica de tehnologie IT si Internet, care nu putea fi ignorata daca cursul se doreste a fi actual.

Alaturi de prezentarea modelelor teoretice, cursul contine un caz ce va fi prezentat ad-hoc inca de la inceputul cursului de catre un cursant voluntar care a mers pe ideea francizei si va expune din experienta sa dificultatile unei astfel de abordari. Franciza este cea mai facila abordare la prima vedere daca ai un capital de investit si doresti sa pornesti pe cont propriu, este printre primele optiuni in cazul unui start-up si de aceea sunt sanse mari ca cineva din auditoriu sa fi incercat acest model. Altfel, se va alege un voluntar care isi va prezenta povestea si facilitatorul va modifica discursul in functie de aceasta, prezentand conceptele teoretice in lumina experientei prezentate si invitand auditoriul sa expuna pareri pe masura ce conceptele teoretice sunt dezvaluite. In plus, alte două minicazuri vor fi înmânate cursanților și vor fi dezbatute.

De asemeni, cursul are ca obiectiv amintirea unor subiecte mai putin familiare, cum ar fi derularea afacerilor in strainatate sau conducerea afacerilor in familie, pentru a furniza idei in plus de dezvoltare a afacerii sau de identificare a unor oportunitati.

Nu în ultimul rând, dorim ca subiectele expuse să constituie o sursă de inspirație și de motivare pentru antreprenori și să determine o ordine mai corectă a priorităților pe care se consumă resursele limitate ale unei afaceri mici.

Recunoscând ca durata de trei ore este suficientă doar pentru deschiderea unor căi spre antreprenoriatul de succes, cursul conține și o listă de lecturi constând în cărți fundamentale de afaceri precum și materiale alese de pe web cu articole valoroase pentru dezvoltarea personală, abilități de management și problematică specifică antreprenoriatului.

Ram Sharan in Bucharest

2011-10-27T19:40:00.009+03:00

I was one of the thousands privileged to listen to, and interact live with Ram Charan in Bucharest. Mind the fine irony between "thousands" and "live interaction" and we will move forward to the good stuff :). (But it was really a great opportunity for which I want to thank my manager.)

The workshop was a fast forward of concepts in Ram Charan's latest books.

1. The first session was called "How do leaders cope with difficult times". They do stuff like these:

Always keep an eye for unusual places in business to spot new competitors - using technology in a globalization era, the competitors can be anywhere. Web sites for instance can make you visible anywhere you need to, and freedom to travel, work and do business anywhere in the world attracts talented people in new markets with multiple opportunities;
They are "fierce" in their journey to achieve their results;
They are "visible"; they leave their ivory towers and interact with people in the low ranks; they aknowledge these people have the potential to emit the next improvement idea and the correct image of the business reality; ivory tower - no good. As a personal comment, I was for a year a direct for a manager that wouldn't listen to people in their own team. This ended up ugly for her and the organization and I promised myself then to be smart, to learn from other people mistakes and never to do the same;
They are credible;
They are very sensitive about how they choose to allocate their time;
They trust themselves and therefore make other people trust them;
They are over optimistic and over pessimistic at the same time: something like "hope for the best but prepare for the worst"; or better, "things will get ugly but we will be able to cope";
They have courage;
They are determined and their actions are decisive - this goes alone with the second bullet, they are "fierce";
They pay attention to resource allocation and hate waste - sounds like something very general, but it really refers to being able to choosing and to let go of some opportunities if pursuing to many means dissipating the resources of the organization. He talked about the classic Steve Jobs coming-back to run Apple. Apparently, out of 26 de projects, Steve Jobs kept 5 that allowed everybody to focus and create exceptional products. Personal comment: Steve Jobs also had the reputation that he wouldn't listen to anyone when making decisions.
They take care of key-employees: during difficult times, these are the first persons hunted by other companies; this is a fresh idea that did not occurred to me before; I always thought difficult times are difficult for employees, period;
Communicate and make sure the information flows smoothly in the entire organization; again, not Steve Jobs-like;
They drop business lines that are not bringing cash;
They look outside-in at their company - as seen by the clients, as seen by the partners; but not as the company sees itself;
The budget allocation is dynamic and flexible - this will make a finance specialist such as myself stop and think. I always looked at a budget as something fixed, analyzed the variations and tried to correct; I never thought being flexible with your budget can be a competitive advantage.

I put in bold above the three most important success factors for coping with difficult times, in Ram Sharan's view.

Ram Sharan suggested the next question for self assessment: Which is my personal brand from an execution point of view? I am perceived as a person that is effective and gets things done? - which transited to the next session, Execution.

2. "Execution" session had the same title as the book and had some of the concepts in it.

Each quarter, perform the following analysis:

Which are the 10 companies that are known for their ability of getting things done?
And how do they do this?

Setting priorities is key in Ram Sharan's speech:

- Determin 3-maximum 5 "laser sharp priorities" for you and your directs;

- Measure progress for the asssigned priorities.

create deadlines because they create discipline, focus, energy, cooperation
maximum 3-5 deadlines per quarter

- For each dead-line, create a dashboard that shows completion percentage, in a manner that is transparent and visible to everyone. This stimulated collaboration;

- Analyze progress:

what causes the results; if the results are negative, analyze the causes; if they are positive, do the same; congratulations when the results are good is not enough; you need to find out what went well and see how you can replicate that;
are these results based on some external factors and contexts? if yes, how can you benefit most (or minimize negative impact) and what should be done after they are gone?
analyze people's performance; if the results are good, then the cross-departmental teams are good; if the results are poor, the the cross-departmental teams do not work.

3. Talent masters - "Right people in the right jobs"

-Define three success criteria, the example below has been created through interaction with the participants and it refers also to Apple:

Different Consumer Experience
Modern, Sexy, Young
New Team

- Match internal abilities with business needs

- Provide real-tine, constructive, specific, on one-subject only, 60 seconds long, feedback. Any feedback that is above 60 seconds will not be put in practice (and hurts worse, too, I add).

Feedback categories in an importance order:

Behavior/attitude
Team work
Business/functional/technical

Note the emphasis on the human component (2 components out of 3), while the "hard skills" area is represented by 1 component: business, functional, technical.

4. Create a management team that performs

- Selecting team members: focus on "team player" abilities, helping the team to win, not competing against each-other.

- There is a deviant member in each team: identify that persona, bring it on track or eliminate her.

- Perform real time coaching and benchmarking with your competition.

Ram Sharan's entire speech was based on people and their abilities as being the primordial solution to all problems; or at least the solution generator. This is an idea that is embraced by everyone, but is seldom practiced. So I guess there lies your next competitive advantage: right people, right organizational culture is very hard to get for everyone.

Change Management

2011-09-28T07:55:00.000+03:00

Change management refers to the set of activities necessary to ensure acceptance and support for the program and its results at both organizational and human level. The existence of a formal change management plan results in increased Return On Investment (ROI), reduced risks associated with any large-scale program and supports those involved in obtaining benefits for which the program was created.

Change approach: Similar with the levels explained in Program governance, we need a two-tier management structure to carry out Change Management activities. A Program needs a board of senior management to meet once a month or at major phases, with the responsibility to review the activities, take decisions and allocate resources to implement change. This can be the Steering Committee. The second level is the Change Management team, whose roles are:

ü Define the risks and problems that could slow down or endanger implementation and recommend strategies for their elimination, with particular emphasis on organizational and human factors;

ü Carry out activities to disseminate information and training to raise the knowledge and skills that will be necessary after the adoption of program results;

ü Prepare personalized plans for top managers and employees affected by the change, which contain presentations of the new business processes and their impact on how operations are carried out routinely;

ü Recommend strategies to minimize the impact, additional effort or difficulties in ongoing business after the change;

ü Encourage greater involvement of the sponsors and top managers in the program;

ü Establish a support system and help those in difficulty after the implementation of program results;

ü Disseminate and communicate the anticipated benefits continued to ensure acceptance, enthusiasm, performance and to support those affected;

ü Recommend the necessary organizational changes, including hierarchical and human resources (performance assessment, compensation, benefits, rewards);

Analyze together with those involved and recommend changes in the hierarchical structure, policies, procedures and job descriptions amended in accordance with the changes.

Program Governance

2011-09-25T10:15:00.004+03:00

“Program governance” is the name used for all formal mechanisms that must be put in place to ensure alignment between business objectives and deliverables of the program, and ultimately, to ensure the success of the program. These mechanisms are organizational structures, methods and processes that allow the Program Manager to assess whether the program is on track and to order corrective actions if necessary. Their goal is to provide:

1. A structure (virtual team) for necessary decisions related to the program;

2. A method for providing focus to the common goal of all parties involved;

3. A risk and stakeholders requirements management process.

Successful implementation of a program will be managed by managerial teams at four levels, with a clear role and performing a set of activities appropriate to their level of competence:

Level	Participants	Frequency	Objectives
Executive Committee	· C-level · Program Management Team	Quaterly	· Status · Sets strategic direction of the program
Steering Committee	· Sponsors, managers · Program management team	Monthly or on major deliverables	· Status · Ensure the necessary resources · Escalation
Program management team	· Project Managers · Technical Leaders	Weekly	· Progress · Coordination · Escalation
Project management team	· Project Managers · Technical Leaders	Weekly or on demand	· Status · Coordination · Solutions approval

The role of each entity is explained below.

The role of the Executive Committee

The Executive Committee shall meet quarterly or more frequently depending on the health of the program and will perform the following roles:

ü Define the vision of the program, the strategic direction and the appropriate tactical objectives;

ü Ensure alignment of long-term strategy and program direction;

ü Monitor all aspects of high-level planning, time, cost, benefits, deliverables and support to achieve the ultimate program benefits;

ü Support and implementation of decisions required to change business processes and practices;

ü Review and solve problems that require executive action, such as major changes and strategy issues;

ü Establish and maintain strategic relationships with suppliers and customers involved in the program.

Role of the Steering Committee:

The Executive Board will meet monthly, at major milestones and at the request of program management team, with the following objectives:

ü Review of program status;

ü Approval of deliverables;

ü To make decisions beyond the authority of the Program Manager.

The Role of Program Management Team:

The program management team includes in addition to the Program Manager, the Project Managers of the components and can include a Program Assistant. The program management team meets weekly and has the following roles:

ü To plan the following activities and focus on program objectives;

ü To ensure integration, coordination and correct sequencing of interrelated projects;

ü To define milestones for the high-level deliverables of the program;

ü To initiate and prepare governance actions (escalation, meetings, etc.);

ü To provide progress reports and communicate to those interested;

ü To communicate and disseminate information on best practices and reusable components from project leaders;

ü To take proactive measures to manage risk;

ü To implement the communication plan and change management;

ü To ensure quality program deliverables.

The Role of Project Management Team:

ü Planning and coordination of projects, taking into account the vision, objectives and constraints of the program they belong;

ü Monitoring and reporting for the project;

ü Provide necessary material and human resources for the project;

ü Risk management and changes in the project;

ü Budgeting and financial analysis;

ü Quality assurance.

Choosing the Right Program Manager

2011-09-20T19:03:00.002+03:00

In this post, we presented the need for the Program Manager to actually be a senior manager, able to influence and manage the inherent complexity of a program. However, adding a new “hat” for a person in the company's operational management is not a good solution. For example, it is not recommended to appoint the IT head of a company's department as Program Manager for ERP implementation, for several reasons:

1. Program Management is a full time job, and it often requires work overtime. Add this to the daily duties of Chief of Department and you have the recipe that at least one of the two objectives will suffer. Unfortunately, most often the program is the one being compromised, which means that while daily operations are still going well, but the strategic objectives of the company, medium and long term, suffer or even are abandoned.

2. A department director and program manager have conflicting interests. The program manager must provide and support the change, while the Department Director may be interested in maintaining the status quo for carrying out daily activities easily. Again, the second interest of the two will succeed, which means sacrificing the interests of medium and long term for the comfort of the moment.

3. As the Project Management, Program Management is a profession in its own right, with a Body of Knowledge that has emerged as an International Standard that requires specialized studies necessary for being productive and not reinventing the wheel.

However, from the three constraints expressed, the third is the weakest. It is possible for the managerial skills of a director to be transferred in a relatively short time towards running a successful program.

So where to find the right Program Manager?

1. The easiest way, if the organization permits, is the recruitment of the Program Manager from the Project Management Office. If you already have experienced and successful Program Managers, the subject no longer needs to be discussed here. Even a Project Manager with experience and potential can be a good solution.

2. If you do not have / want the establishment of new structures such as the Project Management Office, you can still recruit the Program Manager from Middle Management. It is then required to release him/her from other operational duties and allow him to report directly to the executive management, such as C-level or vice-president. This is to make sure that when the program has conflicting interests with those of the functional manager, the Program Manager has access to the highest level for decisions that are in the strategic interest of the company.

3. An external Program Manager, contract based, for which you can collect references on, is also an approach that will lead to success. We emphasize the word references, since the professions of Project and Program Manager are very attractive; there is a risk to be overwhelmed by a large number of candidates and to find it difficult to choose and even to make a wrong choice. The advantage is that an external Program Manager will have an objective opinion on what goes wrong in your organization. In addition, it will be a professional Project or Program Manager, and you will not need to train him or to wait long to get 100% productivity from him.

4. In terms of soft skills, you have to look after a Program Manager who knows how to manage both horizontal and upward. He or she should not be intimidated in front of a board of directors that are starring at him, should be able to support their recommendations in front of a vicepresident and should be able to summarize a problem in a few words and make a recommendation for the solution.

5. In terms of business knowledge, look for a Program Manager that understands business objectives, is creative in finding alternative solutions to achieve them, and is able to support its business case in front of the directors, including using future profit figures,

A good program manager is hard to find. Therefore, it may be easier to train a person with potential from within the organization than to identify a person with all these features. However, once identified or developed, consider such a person as a key employee of the company to support future initiatives.

Program Management versus Project Management

2011-09-17T21:22:00.004+03:00

The next blog posts are part of a material I'm working on, called "Project Management - A Managerial Approach". Hopefully this will end up to be a down-to-earth, Guerilla book, that eliminates fluffy theory while keeping what I found from my experience to be valuable practices. The book will cover Project Management, Program Management and Portfolio Management.

The definition of a program: The program is defined by its great extent over time and how dramatically it affects an organization. The program is actually a series of projects that can run in parallel or sequentially, with interdependencies between them. A very large and complex project is often a disguised program, and becomes very risky if not recognized and managed as a program. It is therefore important for top managers to understand the concept of a program, to allocate the right people for Program Managers and to judge whether a program is properly managed.

Program versus Project

It is important to understand the relationship between programs and projects as a program is often mistaken for a project. Inadequate management (such as a managing a program as a project) has a strong negative impact because by definition a program is aimed at large-scale transformation. Similarly, the risks are much larger for program and have a different flavor. Therefore, poor management is likely to make these risks materialize easier (see chapter 12.2 Programs’ Specific Risks). The complexity relationship between Program - Project - Phase - Task – Deliverable is illustrated below:

ü The program is mostly oriented at the organizational level, aimed to produce a large-scale change that often includes organizational standards and processes. In order for a program to succeed, it is necessary for several departments, suppliers or solutions components to collaborate. This is usually achieved by having the components organized in projects that must integrate. Therefore, a program must contain a component of managing human resources and communication that is given a great importance. By its dimensions, a program aims to achieve several benefits for each of the recipients of its components, so the definition, management and measurement of benefits is very important in a program;

ü The project aims virtual team, which does not cover the entire organization and has an average scale. It has one major objective or benefit;

ü Even a medium side project is hard to be managed a whole package, so work is divided into phases with clear deadlines (milestones) that determines the concentration of efforts towards achieving deliverables within the stated time. A phase has a common goal, which serves as an input for the next phase (e.g. the design of a new product is an input for testing on its target consumers);

ü Tasks have a short duration and are aimed at contributing to a deliverable and usually are allocated to a single person;

ü Deliverables are the tangible results of the activities. Examples of deliverables are: product specifications, job interview, sales force training material, training test results.

In terms of management, the major difference between a Program and a Project is explained below:

Projects that are part of a program have a different set of risks as compared to the risks typically faced by a stand-alone project. These are:

ü Insufficient level or power to escalate issues. Often, programs require large amount of resources, or resources that are precious for the daily business. Managers will not be easily convinced to extract such resources from daily business, and only a convincing speech of a senior manager will convince the executive level of the opportunity of such a resource allocation. The Program Manager must be then able to express their arguments in front of the executive managers, including talking competently about figures, future profits, and why the effort of the organization is beneficial in the medium and long term. Therefore, a Program Manager must be in fact a senior manager with the power to influence the organization and obtain the necessary resources for program success. Failure to earn resources for a component of the program will have an impact on other components, so the Program Manager needs to be able to prioritize, and a get the resources with the most beneficial impact from a limited set of resources.

ü Resistance to deep organizational changes. More than implementing a solution, a process, a program will require changing how a company works, how people think, the values and the company culture. The deeper the targeted change, the greater the resistance, which will channel towards the rejection of the program deliverables. For instance, when implementing an ERP solution, the employees will be required to introduce all the bills in real time, every day, to keep track of inventory. Senior management will be able to see if this not respected by using ad-hoc reports. It is understandable that the ERP solution will become subject to criticism, justified or not, and senior management will have to convince employees of the utility of the system, that their work will be easier if they respect this discipline, and to reward additional efforts of those who will embrace change.

ü Redundant efforts. A Program Manager’s role is to identify projects that may need the same deliverables and put some effort to optimize the reuse of components. Being a large-scale effort, this optimization has a great impact on the program and its deficiency can lead to delays in the chain of projects.

ü Aggressive timeline that leads to parallelization of many activities that would otherwise have been made sequentially. This leads in turn to rework on deliverables that represents wasted efforts. Business reality requires aggressive deadlines for any project or program. Therefore, the Program Manager decides to start work on a set of assumptions and incomplete deliverables, and if they will prove to be inaccurate, to revisit the deliverables for adjustment.

ü Cultural differences between team members. If a program in a multinational, global companies, the team is very often virtual, with members from different nationalities. Such approaches are very modern and very often practiced, though not always with the right attitude. In this case, it is important the tools that will be used for communication and how communication is formalized, managing cultural differences, time zone, language and lack of face to face interaction. The Program Manager must practice tolerance, empathy and flexibility to achieve optimal results.

Program management versus portfolio management: The portfolio is a suite of projects without dependencies between them, while the program is a series of projects with dependencies between them. An example of a portfolio is a suite of projects to various clients of a service company. An example of a program is implementing core business system (e.g. an ERP).