 Project Management as key for competition
From startups to big corporations, effective Project Management is a main a drive for change. Every major innovation starts as a project which, if validated, evolve into another with higher budget, bigger scope and may eventually become a process within a company. Effective project management is a key to keep up with today’s competitive world, since it enables growth by adapting companies to constantly evolving markets and increasing customer’s needs. Creating or killing innovation Poor planning and implementation of projects may harm or even kill innovation within a corporation. Often a project is set as a test to validate certain hypothesis, and a lot is at stake, since the project success is inherently seen as a binary response to a bigger, more strategic question. If project fails, it means that no resources shall be allocated into specific innovation, as inefficient project manager may try to bury the whole idea rather than have their poor management uncovered as a result. External contractors: the problem of overpromising When managing external contractors, the clarity of communication and good expectation management are of utter importance. If the scope is not clear and the quality can be discussed, rather than measured, problems will most likely arise. The time constrains are also important: often Senior Managers of consulting companies promise certain deliverables and count on burning out staff with long working hours to deliver towards excessively tight schedule. Results? Dissatisfied client and high employee turnover. Startup world: everything is a project In my startup experience everything is a project. I implemented agile methodologies from tech to marketing, as a way of thinking and doing. For example, the idea of experiment driven marketing is to deliver and test small hypothesis in limited time, building on those that are validated and rejecting those that don’t work. With lack of solid, established processes, projects are seen as foundation of day to day activities. Consulting: the art of closing budget and scope Although I have never seen a project that would fail entirely, when managing clients on a project basis I had to often mark several items as out of scope and deal with tense situations with a client. What I find it the most challenging in project management so far is to deal with abusive behaviour of clients who first negotiate project scope to fit into smaller budget, which is usually discussed and agreed though eliminating features and deliverables, and then try to stretch out the project to include those parts anyway, without accepting additional costs. Marrying agile approach with sprint limitation toward specific result often means that clients want more functionalities in a solution, without compromising other features. Even though in my experience this was never a live or die of a project, it definitely created tense moments and did not have a positive impact on overall relationship.
1 Comment
 Risk management:
Modern project management methodologies give great importance to risk management, which is a structured process that allows the manager to identify, plan and manage risks during planning and implementation of the project on a step by step basis. Risk analysis processes include:
There are multiple examples of project risks, some of them could be:
PRAM is a methodology that makes it possible to analyze the risk associated with the project and manage this risk. Properly applied, it increases the likelihood of successful completion of the project. The methodology process consists of two stages: risk analysis and risk management. Personal perspective From my perspective, the first step is to identify risks, that is their characteristics in relation to the project. Qualitative analysis is the process of hierarchizing risks by threat and probability. Then, for the higher probability and higher threat ones, risk response should be planned accordingly, which consists on developing solutions that reduce risks and increase chances of project success. The most important part is tracking of identified risks and recognizing new risks by its continuous evaluation.  The life cycle of the project determines the diversity of situations occurring during its implementation. One of the first tasks of the project manager is to define the scope of work to be done and to divide tasks between members of the project team. Defining tasks is the first stage of the project manager's work throughout the entire life cycle of the project. At this stage, the customer specifies the requirements and the project manager agrees on the most important aspects of the project. Regardless of the form in which the requirements are agreed upon, the five basic questions must be answered in the definition phase:
Project Business Case Business case it the main document needed in order to document the value of the project and make sure everyone is on the same page in terms of scope and deliverables. Since business case is a base for the project development, it can become a great tool to look up to and check whether the team is on track with what was initially intended. Project Business Case, if done correctly, can be sufficient to start a project. Good PCD contains information on:
In terms of the “Why”, nothing explains it better than numbers and results predictions. The Project Measurement Framework presented in the supplementary material doesn’t specify the exact way of weighting and selection criteria. Clarifying that point may be crucial to really get into why a project is being run and make sure it is treated with required seriousness and prioritization within the organization. One of the most difficult things during the project is to manage stakeholders who are also co-owners of different parts of the project. If done well, the project is running smoothly and without delays. This is, unfortunately, rarely the case. Now, to the point:  Sometimes you have to be extremely clear if you want the project to go without delays. Other times, you just need to present the ultimatum in a clear and simple way. I like to do it with a touch of humor, this is why I use the rule qui tacet consentire videtur, also known as he, who is silent is taken to agree, in most emails to decision makers related to the project.
Wait. Stop. What? Decision makers? Well, sometimes the given is, that people should be validating different streps and processes are unresponsive. This is when you, project manager, have to think about the decision to be made. My internal workflow goes as follows:
Dear John Doe, As you know, I need to send the composition to be printed today if we want to have the billboard ready before Mondays conference. I still don't have the feedback from you. If you don't reply till tomorrow 11 AM, qui tacet consentire videtur will be applied. Have a great rest of the day! Now, taking the decision without the actual agreement of the key decision maker may be difficult, and I do not encourage you to apply it unless you are sure about your position within the company and the amount of decision making power you have been granted. In most situations though, personal fears in a professional level are the reasons why projects are not going further: someone is being a bottleneck or just gets unresponsive and then you are the one who is not getting things done. How about taking the right decision yourself? In many cases this is gonna be the best you can do. If you're a PM, lead the project. Worked for me so far, but then, you know what's best. I like when people talk about Agile and different implementations. I like to listen to them, occasionally saying “Mhm”, “Yes”, “Of course”, when I am being presented with a bunch of papers with giant business plan, a year of initial implementation, at least year of development till the product can meet the market and get introduced to demanding client. Where are we having the principle of people over processes here? Response to change? Software over documentation? I think this is the time, for all of the agile-hunting lean lovers, to introduce the basic, very first, agile manifesto, on which all the frameworks (yes - these are only frameworks, someones ideas of how to make this four line into five hundred book based on which you will later on sell 600 USD ´worth´ certificates) are based. You have never heard it? Here it goes. I strongly recommend to learn it by heart: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan If you feel like you want to have it tattooed on your chest, or at least agree strongly with this being the core, you can sign here the very original statement. Now, Jim Highsmith says “We not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker.”. Completely agree. What is the key? Dynamics. Constant observation of the market (benchmarking will be covered here a lot) and quick response are the key of agility. The customer will not likely change a lot in a couple of months, but what if a solution does? We have to be prepared with that. I remember when launching eRural (one of the very badly planned relaunches with an important lack of financial planning and estimations by the way. Happens) we were constantly monitoring the core competition. We based some of the UI solutions on the conventions used on other sites, including this one. A week before official beta online, they changed all the layout. We were stunned. I decided then to maintain the same one, change some bits for better UX, and see how it goes. We were past deadline, devs were on the edge of their nerves, we did not have time for massive replanning on core design. The small changes we actually did were relatively simple, but still, we should have been a step ahead. We were not.  Lets now see the 12 points of Agile Software Development, and apply the principle of common sense to make it even clearer:
I like to call VPM sweetly as very problematic management, mostly due to the fact that it has many of these little problems that can easily translate into huge loss if badly handled. You may as: allright, as a regular PM you face the same challenge. Yes. And No. Virtual Project Manager has no “real” team in house, so the lack of communication should be compensated with even bigger dose of trust - specialists from top business schools used to advise. Right. For me, personally, it failed dramatically. You can not be completely people centered as a VPM, specially when talking about huge teams geographically disperse. You have to be tasks oriented: clear, helpful, concise and demanding. Than you can be cool and understanding, of course, but it is the project that comes first.  Being a virtual team leader I was going to skip the universally known definitions of WHAT is a virtual team, since even if someone doesn´t know the exact Peterson & Stohr one, can probably guess that there is a purpose (project) and people (team), globally dispersed, that work together towards achieving a goal related to the project. So far so good. We have a great theory, a bunch of technology that is helpful in communication and actual task management, but then comes the first big problem: Lack of understanding of the task in a percentage of the team. You applied Einstein's principle of making everything as simple as possible, but not simpler, you sent clear and concise email with clear direction, there were no questions and then, out of the sudden, the task is badly done. What went wrong? Well, maybe nothing. Sometimes you just have to assume that some part of the team will perform worse than others. But if it is an important part of the team that had issue, that you should double check the implementation of the following suggestions.
  How have I done it and why it always “depends” There is absolutely no strict recommendations in terms of effective VTM. It will always depend on many factors: the structure of the team, culture of the company, budget, location, type of project, among many others. I worked managing virtual teams that both know, and did not know, each other, and the rule I decided to apply after many failures and observations was for them not to know, nor interact, with each other, maintaining communication with team leader and managers. That obviously asks for some clarification: it will depend on the team, always. In this case, the job to be done was little demanding, highly repetitive and, to be honest, quite boring. That leads to many possibilities of people willing to cheat the system, for example, by subcontracting others and paying them less, creating the pyramid, etc. if wanted. This is precisely why I implemented complete monitorization of the process: anyone can be checked any time during the day with Skype call, the platform tracks exact times of submission of the tasks and everyone has to communicate if absent for more than 15 minutes. Before I decided to do it this way, I read many wise books on effective administration where the flexibility and people orientation were shining like a giant star in the vast universe of management, and I thought “Wow, that is the way I want to do stuff. No supervision, total trust, complete transparency, team building, mutual understanding and thrive for the best in the project”. In my executive uthopy I was already seeing everyone waking up super motivated, sitting in their home offices, spreading pure happiness around their households for another sunny day being able to work with my magnificent projects, knowing that they had flexibility, trust, attention, and could schedule their life as wanted, with my blessing for (almost) everything they might dream of. Unfortunately, that did not end up very well, since illusions are usually not a reflect of reality: duplicate content, false emails for linkbuilding, disappearances and multiple, sudden hardware failures were only some of the problems that arose on the idyllic ground of my perfect board. That gave birth to an insightful moment of reflection, which led to the beginning of a new era, an era of scheduling, monitorization and double checking. Oh, there is still flexibility, but there are rules to be obeyed as well. But this is so, so bad!
Again: There is no universal truth in VPM, and there is no just and only one good way of doing stuff. I would never recommend this strategy to work with designers or engineers, among many others. There are different delivery methods for every purpose, and different leadership needs to be applied for different teams and even team members within the team. Sit down, look at your team, think of the goal and apply the strategy that will help you meet it in the best way. Remember though about a few basics:
Of course, with small teams on a long term, you can apply all the awesome techniques of interactions, challenges, competitions and relationships within team members, but I would think about the goal and structure before, and apply this into specific cases, above all, when occasional meetings face to face are possible. |