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?
Tuesday, June 30, 2015
- Become more business oriented learning strategic thinking
- Having to work with remote multinational teams learning the cultural nuances
- Become more involved with futuristic technologies learning mobile, service orientation, and security areas
- Learning to work with multiple tools for both process and analytics
- Understanding agile framework as much as traditional project management framework learning to know when to apply each or a hybrid form
- Learning to manage external and internal stakeholders in the business learning to negotiate better
- Getting better at managing risks in multifaceted areas (PESTLE) besides just SWOT
- Being more accountable for quality to compete with the agile thinking
- Promoting project management in organizations much beyond PMP certification
- Understanding the impact of growing regulatory environments on projects
Sunday, May 31, 2015
Thursday, April 30, 2015
Meetings are everywhere. External meetings, internal meetings, individual meetings, group meetings, team meetings, daily sprints, sprint reviews, retrospectives, etc.
Often, people claim a meeting is successful. There are meeting notes distributed too. But, what determines a successful meeting? I am not focusing in conducting an effective meeting on meeting etiquette but evaluating the success of a meeting.
I recall a great book on How I raised successfully from failure to success in selling that gave the tip. A successful meeting is one that has the next meeting identified. But, wait a minute, is that it? So, if recurring meetings are set, then isn't all meetings successful?
There lies the myth. The successful meeting is the one need having clear action items identified with action owners and due dates so that the next meeting serves as a follow up. The follow through happens in between these two meetings ensuring incremental and iterative progress closing the sale, improving processes, updating progress, identifying risks, lessons learned, and removing obstacles.
If follow up meetings are proving to be action owners not providing updates or providing vague updates, then it is time to evaluate if the right owner was identified or if the owner is capable and having bandwidth. Identify escalation paths if necessary. Of course, this is true when that action item is still applicable. If a solution is identified or closure is recommended, then it is also important to ensure collaborative commitment and if any additional follow up would be required now or later.
Would you look at your meetings and evaluate if your meetings are successful? What other criteria would you add outside of meeting etiquette to evaluate the outcome of a meeting?
Monday, March 30, 2015
Saturday, February 28, 2015
2. Big upfront requirements gathering
3. Gathering requirements upfront saves cost
4. Analysis follows requirements followed by design
5. Project Management is not part of software development
6. High degree of documentation needed before starting work
7. Customer sees work after all the work is developed and tested
8. Testers need not be involved early