Natalia Bandach | Project Manager
  • Growth
  • Insights
    • Marketing
    • Startups
  • Blog
  • Contact

PROJECT MANAGEMENT: WHAT IS IT FOR?

5/8/2018

1 Comment

 
Picture
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

PROJECT RISK MANAGEMENT

3/7/2018

0 Comments

 
Picture
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:
  • Risk identification
  • Risk estimation and evaluation
  • Planning risk responses
Examples of project risks:
There are multiple examples of project risks, some of them could be:
  • External - Related to legislation, economic situation, exchange rate, competition, lobbying, etc.
  • Internal - Related to staff fluctuation, conflicts in the team or lack of management support
  • Technical - Related to choice of technology, standards or certificates
  • Technological - Related to implementation or exploration of chosen technology
  • Financial - Budget shortage, scope modifications, etc.
PRAM
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.
0 Comments

What is project lifecycle?

11/8/2017

0 Comments

 
Picture

​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:
  • What problem does the project involve?
  • What is the purpose of the project?
  • What sub-goals must be implemented to achieve the primary goal?
  • How do we assess whether the project has been successful?
  • Are there any predictions, risks or potential obstacles that can affect the success of the project?
These, along with the scope of the project, shall be the main pillars of Business Case.
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:
  • General goal of the project
  • Value provided for the company
  • Time and scope
  • Resources required
  • Proposed solution
  • Team and roles
  • Main stakeholders
  • Information on sponsor
All of which are covered in the supplementary materials PCD. With internal projects, I believe a good addition would be to add the success criteria mentioned before. For technical projects, it could go with a definition of “done”. Being on the same page in terms of how we evaluate the efforts and results is crucial to objectively measure the project.
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.
0 Comments

Making stakeholders respond - qui tacet consentire videtur

7/17/2015

0 Comments

 
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:

Imagen
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:
  1. Why this person has to validate the decision? Is it crucial?
  2. Do I know what should be done in the situation?
  3. Do I know what this person is likely to respond?
Depending on the outcome, the near-deadline email 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. 

0 Comments

Agile manifesto: something to remember

4/26/2015

0 Comments

 
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.

Imagen
Lets now see the 12 points of Agile Software Development, and apply the principle of common sense to make it even clearer:


  1. Customer satisfaction by rapid delivery of useful software → always deliver what gives your customer most perceivable value
  2. Welcome changing requirements, even late in development → the response to change must be always possible, on every stage. The more usability tests on early stage of project, the better.
  3. Working software is delivered frequently → If you work with SCRUM, try to deliver something great in each Sprint. Try to make weekly Sprints. May be difficult, but will be worth it.
  4. Close, daily cooperation between business people and developers → Speak each others language, make everyone understand the business, not just the code. This is extremely important point in order for everyone to be able to understand why you prioritize certain deliverables.
  5. Projects are built around motivated individuals, who should be trusted → Aaah, the trust. Something we might have an issue with. What may help here is on what are you going to base the trust. Everyone in the company should be trusted, because being there should be always one of the best places they can be for relatively objective reasons: growth possibilities, opportunities within the company, flexibility, salary… etc. Shall the trust be based on that? Would you retain top talent in a place with low salary and bad conditions? Why would they be there while having a possibility of being anywhere else? Everyone thinks about their own best. Try to make this the principle of trust, and deliver them the best.
  6. Face-to-face conversation is the best form of communication (co-location) → If possible, always go face-to-face. If not possible, everything that is possibly closest to that (Skype, Hangouts, etc.)
  7. Working software is the principal measure of progress → Make it working software instead of documentation. Use it. Test it. Reuse it. Try to sell it on early stage to see what the customer really wants. Just make the stuff work and be out there as soon as possible.
  8. Sustainable development, able to maintain a constant pace → The team should get used to the pace of work. If you rush too much, the burnout is inevitable. If some weeks are much tougher than others, the inconsistency may translate into fear (why do we have to rush? is there anything we should be worry about?) and fear in the team is never a good thing. Make people feel comfortable and safe. Maintain constant pace.
  9. Continuous attention to technical excellence and good design → I don't think this principle need any explanation. You need your product to be understood, and you need it free of bugs. Absolutely basic and incredibly important.
  10. Simplicity—the art of maximizing the amount of work not done—is essential → Make everything as simple as possible, but not simpler. Always. We come back to the point of: if people don't understand the product, they are not going to buy it. The concrete value proposition.
  11. Self-organizing teams → Interactions, and interactions, and interactions again. Make the team organize itself. Let them pass the tasks to each other, manage the Kanban board as preferable, solve the problems that may make the team not deliver on time. Being a manager is  like being a host on a party. Prepare everything, make sure everyone is comfortable, but never force things (important point is the change of leadership style according to level of team maturity, I will cover it shortly). 
  12. Regular adaptation to changing circumstance → In business, everything changes quickly, and to survive, you have to adapt. Being able to see the trends and catch the cores in terms of profitability vs sustainability is what we want to focus on in the process of market change. Lets make it a weekly meetings first. Lets then see how it goes.
0 Comments

Virtual Project Management: principal challenges with virtual teams

4/26/2015

0 Comments

 
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.
Imagen
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.

  1. There is no such a thing as common sense in VTM. Everything needs to be explained and set.

  2. Always double check if everyone understood the task.

  3. Make sure not to base your guidelines on information some member may not have previously received/studied/etc.

  4. Never suppose that something should be known by default.

  5. No news are not necessarily good news.

Imagen
Imagen


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:

  1. Apply the rules at the very beginning: once you created them, any change may be perceived as desfavorable an unjust.

  2. Make sure that everything is understood: ask twice and answer every question before the tasks start

  3. Be visible and present all the time, but communicate when necessary. Do not over communicate, cause then important messages may be lost, but also, make sure everyone know you are there for them.

  4. Let your virtual personality mimic natural communication as much as possible: to be demanding does not mean you can't be fun  and chit chat a bit, right?

  5. Make the virtual meetings effective: force engagement, keep track of all the interactions, speak slow, explain and then double explain and, of course - ask questions.


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.




0 Comments
Forward>>

There is a science to success, and it's called persistence

  • Growth
  • Insights
    • Marketing
    • Startups
  • Blog
  • Contact