Tuesday, January 31, 2017
Saturday, December 31, 2016
The experts in the field agree that a project is a temporary endeavor to create a unique product, service, or result. Inherent in this definition lies an inexorable relationship between these two disciplines. The project management is a set of processes, tools, and techniques that is indispensable to bring a product into the market. Therefore, a product cannot be delivered without the strategic focus on execution that only the discipline of the project management can provide through the phases of initiation, planning, execution, control and closure.
Does that mean the product management is a subset of the project management? Definitely not! I say this with so much certainty because project management is temporary in nature unlike product management that has a longer time horizon. Consider bringing to market a new hybrid car that runs purely on water! The product management may focus on generating the ideas, evaluating the alternatives, assessing the feasibility, and creating a business case at the beginning. Hence, the product management will have to think of a strategic road map of scouting the external and internal environments by applying the Porter's 5-force model. This 5-force model involves the availability of substitute products, bargaining power of the buyers (price consciousness of buyers), bargaining power of suppliers,those that supply goods), rivalry among the established firms, and the threat of new entrants.
Finally, after all the commercial, technical, and operational considerations have been addressed, the business case from product management becomes the starting point for project management to intervene initiating the project charter putting together the scope statement followed by the work breakdown structure and the sequence of activities that need to happen for bringing the hybrid car to the market. Now, if project managers only become tactical, then, they lose the ability to question the inherent assumptions to avoid a strategic failure. This fundamental need is why the businesses label the areas the need to work on as "capital project selection." The "capital" adjective here is a strategic decision making to ensure that the investment of funds, time, and resources are used to maximize the organizational value.
It is therefore evident that the product management defines what and where we should be doing while the project management tells when and how we could be getting there. But, the project management is like the Phoenix bird that ceases to exist as soon as that need of product management through the project management has been served. However, as the product management continues its journey through its lifecycle of development, growth, maturity, and retirement, there will be additional needs that will come up and the Phoenix bird revives itself again. Therefore, the good product managers will know that they need strategic project managers as brainstorming partners and similarly the good project mangers will have more strategic thinking beyond the organizational context to support the product managers. Each profession, as a result, has a symbiotic relationship.
What do you think? Please respond with your comments.
Wednesday, November 30, 2016
Monday, October 31, 2016
- Non-utilized Resources/Talent
- Excess Processing
Friday, September 30, 2016
Among the numerous questions asked of the panel, one question that really struck a chord in me was the question on how to engage a team member as a project manager. Now, this particular topic has been a burning question for me because the most important task facing any project manager or any manager is getting work done through other people. The principle of emotional intelligence is at the epicenter of leading others. In my doctoral thesis, I studied about the relationship between emotional intelligence and various types of leadership styles concluding that transformational leadership was found to be critical for project manager success (Rajagopalan, 2009). Subsequently, I continued to explore using a qualitative research interviewing a number of senior representatives across many industries validating a framework called TONES for middle management transformation through project management (Rajagopalan, 2014).
Synthesizing the ideas again that the panel reaffirmed during the panel discussion, I present below four critical questions. These are:
- Can you do the task?
- Do you want to do the task?
- Do you have time to do the task?
- Is this the best you can do to complete this task?
I have established and managed a PMO in a professional services setting and in a life-sciences setting. Further, I have delivered a number of projects and programs - some platform level and some client driven projects and I will explain below the purpose behind these questions.
- The first question focuses on unearthing the true desire for an individual project team member or a project manager in the PMO. If the person doesn't have a desire to accomplish any task, then, no amount of motivation can help.
- The second question focuses on addressing the fear factor. The fear may arise from a fear of failure or fear or uncertainty. In such cases, if the person wants to do this but has inhibition, I intellectually stimulate the person on why they want to do the task.
- The third question focuses on creating the bandwidth. Sometimes, the person may have too much going on to devote adequate time to complete the task. This question raises what needs to be stopped to free up time required to accomplish this task.
- Finally, the fourth question focuses on continuously monitoring the progress, motivate and energize the person to create a stretch goal to raise beyond their own limits.
Engagement is all about making one feel important and helping them raise above their own assumed potential. Creating this engagement is the seeds for leadership. In getting projects done by people, every project manager therefore needs to demonstrate this leadership.
Rajagopalan S. (2009). Relationship between emotional intelligence and transformational, transactional, and laissez-faire leadership styles of information systems project managers in virtual teams. Dissertation Abstracts International (UMI No: 3359539).
Rajagopalan, S. (2016). TONES: a reference framework for identifying skills and competencies and grooming talent to transform middle management through the field of project management. International Journal of Markets and Business Systems, 2(1), 3-24.
Tuesday, August 30, 2016
Sunday, July 31, 2016
I was volunteering at the #Agile2016 conference this week in Atlanta, Georgia and had an opportunity to support another volunteer friend who was trying to organize an open space session. What was so impressing was this friend's willingness to get over the comfort zone to get in front of a crowd to facilitate this session with the only goal to creating a stickiness of the information gained from attending the conference to others. It was so wonderful to see how this friend exemplified servant leadership forming a habit to facilitate this session.
Marshal Goldsmith (2007) published one of the classic book where he advanced 20 habits for fast forwarding one's career by identifying habits that may be bringing themselves down creating trust erosion in the team. These behavioral traits may be in our own blind spots that we may easily fail to recognize how we are are sowing the inappropriate seeds for our own professional growth while simultaneously bringing the team down. Joshua Arnold (2016) referred to some of these behavioral traits as HiPPO (HIghest Paid Person's Opinion) in one of this presentation at the Agile 2016 conference. Readers are advised to check this classic to get more insights.
It was a classic example for me to see in action how one individual took the initiative to form a habit not only to benefit from his own reading of a classic book but also push the individual limits to get over the stage fear because of the belief that there was something he had the world should know to benefit from. Now, servant leadership is exactly that - leading with others in mind encouraging the drive to excel, acting with humility, and strategically advancing long term benefits over short term quick wins.
This friend proposed the idea at the open space session providing an elevator pitch creating an interest for about a dozen people as he described the 20 habits creating an activity for people to form a group and select one of the habits that resonated with them in groups, create visual images of these habits, and identifying strategies on the impact of this habit and recommendations to eliminate this habit. The amount of time this friend spent at evenings and nights to form the elevator pitch and create stickiness for anyone that may come for his open space session applying the techniques suggested by Laura Powers (2016) really hit a home-run as the attendees to the session appreciated the new packaging on these habits as they emphasized how this session helped them. I was so glad to be part of supporting him in his endeavors.
As I continued to support this friend in this session, I really renewed my own interest in the coaching of such down-to-earth individuals who not only try to improve themselves but attempt to leave the world in a better place than they found it by avoiding excuses. As Carrie Kish and Jurgen Apelo pointed in the various leadership stages of genius tribes and managing for happiness respectively in their keynote address, it is the knowledge that we gain from such selfless individuals and their friendship that makes
What are we doing today to get ourselves out of any comfort zone that we have encapsulated ourselves in advancing the great experience and knowledge that we have gained?
Arnold, J. (2016). How to train your HiPPO. Atlanta, GA: Agile Alliance.
Goldsmith, M. (2007). What got you here won't get you there. New York, NY: Hyperion Books.
Kish, C. (2016). Leadership for genius tribes. Atlanta, GA: Agile Alliance.
Jurgen, A. (2016). Managing for happiness. Atlanta, GA: Agile Alliance.
Powers, L. (2016). The neurology of learning: Your brain on agile games. Atlanta, GA: Agile Alliance.
Thursday, June 30, 2016
1. Manage meetings
There is a lot of practical literature around how to run effective meetings. Instead of going into microscopic details on meeting management, can we not focus on ensuring that every meeting has a clear outcome to accomplish at the end of the meeting? Whether it is 15 min or a day long meeting, having a clear outline of planned outcome will establish evaluating the necessity of the meeting in the first place. Not having a meeting unnecessarily or accomplishing meeting objectives earlier releases so much time that could be used for other productive tasks.
This is where agile thrives because it timeboxes all ceremonies and avoids meetings not necessary. Project and Program Management can also apply the same techniques.
2. Correct your course
Whether it is running meeting or managing the client, things don't always go the way you plan! So, plan for course correction? What's the point in all these "Failing to plan means planning to fail" when we fail to apply it in principle! When a meeting goes on a tangent, correct your course by bringing attention to your outline. When customer requests come out that emphasize lack of understanding or you get a project where you don't know the underpinning the technology, make course corrections yourself by taking an initiative to learn the technology!
In the world of Khan academy, Plural Sites, Course Era, Open2Study, Bright Talk, and so many other MOOC - not to mention YouTube or Vimeo - there is plenty of information available already for people to gather information! So, correcting your own course is totally on you and not doing so is actually taking the team's time away!
Here is also an approach from Agile where there is retrospective at the end of every iteration! Did traditional approaches ask not to have frequent lessons learned sessions? Absolutely not! It is a restriction that project management forced themselves on and the management failed to react to it. In other words, they chose to learn from the lessons and hence succumb to failure!
3. Focus on Training on "Done" criteria
Having a constant baggage on the trunk actually creates so much drag in an automobile which slows the automobile and burns unnecessary fuel! That's why we don't drive - at least technically - with unnecessary baggage, right! Doesn't that principle teach us to focus on getting tasks completed! Coming from lean management philosophy, it is a principle of waste in over-engineering anything to the point that it is not getting done! So, project management can extend these principles to apply simple heuristics in managing their WBS or have user stories that apply the INVEST principle.
In my experience, I have always applied the golden rule of no task having a duration longer than the risk that I can live with the task completing. Most often, no tasks are longer than 40 days and some work package is always getting delivered every two weeks. So, milestones are not 3 months apart! Such thinking still applies earned value principles to make course corrections if a project slips!
Here is where the INVEST principle from agile comes to help where every user story is independent, negotiable, valuable, estimable, small, and testable! So, don't add tasks just for the sake of adding and use the hammock tasks productively.
4. Establish Stretch goals
No matter how much one knows, there is always room for improvement! This is one of the reasons change management principles advocate continuous improvement. The self-organizing theme behind teams in agile setting really ensures that team members are adequately skilled cross-functionally to pick up other people's task to support the sprint commitment! In a traditional setting, we create unnecessary layers. Every team in a traditional setting should have a stretch goal to learn another team's work and practice. Not only does this avoid central dependency on another, it also helps appreciate the tricks of trade and appreciate the service level agreements and standard operating procedure enhancing adherence to protocols. It also lets creative juices flow as one challenges the status quo to do things differently! Only by learning more does an individual become part of a group and evolve to be a self-organized team.
5. Use the tools of communication effectively
Although we all appreciate a wrench and hammer have their distinct purposes, we also realize overly abusing the tools for the wrong purposes damages what we are trying to accomplish more than the tool itself. The same analogy goes with the tools. I wish we can monitor the use of the "Reply to all" button that creates so much email for an organization. People reviewing the emails out of sequence, replying to them in random order understanding parts of pieces, and eventually ignoring it will only cause so much productivity loss - time that can be used for other productive tasks. So, learn to manage by walking around, collaborating using better tools, and avoiding creating so much electronic dialogue that provides no clear documented decision making.
In my experience, these simple techniques have helped build constant productivity regardless of the approach. In the end, what matters is only the results.
Tuesday, May 31, 2016
Maximization of value means within the agreed timebox, the team self-organizes to add the appropriate tasks. The scrum master acting on the team’s behalf needs to hold the definition of done articulated ambiguously by the product owner. Similarly, the product owner needs to be held accountable to the larger committed timeline to the customer not losing focus on the slips in the timeline due to losing velocity in every sprint. The scrum master needs to hold the product owner responsible for capacity planning in a velocity driven team rather than a commitment driven team.
Friday, April 29, 2016
Project Management - Mindset Change (2016, April). Palagai, 1, 8-9.
Thursday, March 31, 2016
Monday, February 29, 2016
- Has the contracted scope of deliverable been met? If not, why?
- How efficiently were the project objectives been delivered?
- How effectively the project stayed on schedule? If not, what contributed to the delays and what processes need to be in check to avoid future schedule slips?
- How well the project management proactively forecasted changes and adjusted the estimation process?
- How satisfied are customers and project stakeholders?
- How did the actual compared to the final baseline plan?
- How did resource availability changes impact the delivery to adjust for capacity planning?
- Did the team work together effectively?
- What individual contributions positively or adversely impacted the project’s quality? How was performance expectations managed?
- What attempts were made to strategically manage the customer?
- Did any work start late and if so why?
- What improvements have to be made on an individual, team, and process levels to positively impact future projects?
Sunday, January 31, 2016
Wednesday, December 30, 2015
- Is starting immediately with a “No” a good approach?
- When trying to ask what the end result will look like, is attempting to over-please rather than understand the business goal appropriate?
- Are both the client facing person and the project manager on the same team as the expert?
- Were any attempts made to negotiate for a acceptable best alternatives?
- Is this project setup to succeed?
- Is this a productive meeting?
Monday, November 30, 2015
- Opportunity cost of the existing status quo relative to the alternative arrangement
- Impact of the alternative arrangement on the immediate needs that caused the dispute
- Timely feasibility of executing the alternate arrangement
- Risk of the alternative arrangement not providing the promises relative to the status quo
- Evaluating the risk profile and thresholds of the appropriate stakeholders who can be enablers of the best alternative
Saturday, October 31, 2015
- P - Passion about people. Project management is all about people management. This is where the transformational leadership elements of a project manager is displayed.
- R – Resourceful around Risk management. Seeing proactively the risks and managing them by maximizing opportunities and minimizing threats
- O - Organized around self to manage all aspects of the project. As the saying goes, if you can’t manage yourself, you can’t manage the people that do not work you in the project.
- J - Justified in constant review of resource utilization including both the human and non-human resources keeping in mind the total cost of ownership on the project managing scope and quality
- E - Effective in leading change seeing it as a vehicle to improve scalability and as a liaison to other business units within the performing and client organization
- C - Collaborative in bringing ideas together letting the individuals become groups and then evolve as teams to support each other
- T - Trust worthy to transform people’s career. This completes the cycle of project where one’s passion for people makes them a servant leader.
Wednesday, September 30, 2015
The general tendency of the requirements document has predominantly focused on what the software should do. In project charters and scope control documents, sometimes we also write what features will be out of scope. The UML diagrams and use cases discuss how the classes should interface and modules should interoperate, for instance. The agile paradigm discusses persona approaches drilling down DEEP property for describing backlog features and INVEST principle elaborating on the characteristics of a user story. Even test cases that focuses on negative testing uses a requirement traceability matrix to the requirements limitedly testing the functionality of what a system shouldn't do.
But, when a system is hacked or inappropriately accessed, the loopholes rests on the inefficiencies in how the system was designed to allow such loopholes to exist. So, how do you avoid these vulnerabilities so that the hacker doesn't exploit these "working as designed" gaps?
While volunteering at the Agile 2015 conference, I chose to attend a section on Abuser stories by Judy Neher from Celebrity Technical Services. It was a great session introducing the concept that a persona of a hacker or disgruntled employee who could potentially have a malicious intent to deliberately break the system. The speaker suggested describing user stories that specifically could break the system or expose the system for mal-intent. The participants in an activity gave examples for a simple user authentication such as the stringent password recycle policy, the use of a double password and picture identification, the use of external devices such as phone, email, or mobile texting to use tokens for validation within a short timeframe before the account is locked, the creation alerts for maintenance for incorrect and frequent access to multiple accounts, the enforcement of HR exit policies on employment dates before the role based access can be authenticated, the validation of human versus robot logging by tracking the spee of password entry, etc. Imagine having such stories to bullet proof the system against malicious attacks on standard user stories and have automation capabilities to constantly check for these loopholes.
I am sure one would say that this would add more time to the scheduled release or limit the stories written per iteration/sprint. Of course, similar to non-functional stories that add some time, the abuser stories also will add time. The need to develop hinches on the type of regulations in the industry, the type of technical platforms used, the time to market considerations, etc. However, the question shouldn't be whether to do them or not but when to do them. If we fail to do them we are increasing the technical debt. A couple of alternatives are to dedicate a sprint or a portion of every sprint to address these abuser stories.
I really think this is an important component of combined technical and product ownership to ensure we see the persona of other types of users and see the system from that view. As good project mangers turn assumptions into risks and control quality, the technical and product owners should be accountable for products that preclude vulnerabilities by design. Abuser stories are a great start. Don't you think so? Share your thoughts.
Saturday, August 29, 2015
Flying over India returning from Mumbai to Chennai, I was browsing the Jet Airways magazine. Often filled with travel recommendations and shopping suggestions, these in-flight magazines have only created a browsing pleasure. But, this magazine had a topic on achieving more with less perking my interest to explore.
It was an interesting read as the article began discussing how the time management pretty much shouldn't be the focus of smart managers. Instead, the article focused on attention management. Based on the time of the day, people can manage difficult tasks that require deep thinking, strategy, etc when their attention to detail is at the peak. Then, as the energy winds down, their attention takes a deep dive. This time should be used for tasks that require less critical thinking. Between these extremes is the reactive attention seeking timezone that should be used for other tasks that require a balance of the two.
I agree that it is a good idea and that tasks require different levels of thinking. For instance, planning for the project, evaluating strategies to grow account, or grooming the product backlog with new features based on the market and reactions from customers and users require thinking different from task or resource management.
However, the article said the urgency of the tasks shouldn't be a criteria for attention management. This begs some thinking as depending upon the role of an individual manager, the urgency of the task, such as a grieving customer on the phone, an infrastructure deficiency leading to business continuity management, or a delayed or poor quality work impacting deployment readiness of a project is not something that can be ignored.
The earlier approach on using Scrumban to think a couple of steps ahead and plan can be combined with attention management to better compartmentalize take at hand and energy/attention requirements to better manage productivity.
Thursday, July 30, 2015
I had a wonderful opportunity to be with one of my mentors in three different client settings. I am sure people in project, account, product, and sales setting have gone through the stakeholder management aspects. Whether it was a formal status meeting, casual hallway conversation, informal dinner meeting, or an internal project evaluation meeting, I found it very inspiring to see how my mentor was skillfully weaving these questions to eliminate ambiguity and establish a solid business relationship. While I added a few of my own color from account and project management, I felt such a strong reinforcement of these questions that I felt compelled to package these questions for the community at large. So, here goes the list. Feel free to add - focus however on strategic account & project management and not bury with technical aspects of platform and feasibility here!
- What are your goals and objectives? Are you interested in market expansion, market penetration, or both? What's your timeline?
- What are your challenges to meeting this goals and objectives? How would addressing these challenges benefit you and your organization financially?
- What are the profiles of stakeholders that you are looking at to satisfy with your campaign?
- What types of population are you planning to target? Why are these targets important to you?
- What types of channels are you planning to use? What data points do you have to support these channels to effectively reach your population?
- How much of your budget are you willing to spend on these channels? What's your exit strategy?
- How would meeting these goals and overcoming challenges enhance the competitiveness of the product?
- If you were to meet your goal, what would this mean to you?
- If these challenges are not met or goals accomplished, what does this mean to you?
- What's an example of a successful campaign or meeting? What data points are you looking at evaluate the effectiveness of the campaign or efficiency of the meeting?
- What's your communication style?
- What's your risk profile? Are you adventurous and creative to try new things?