October 7, 2018

Project and Program Management Insights that matter

I facilitate PMO breakfast meeting of PMI Silicon Valley chapter where a small group of PMO leaders get together to share their insights and success stories, and get advice for potential challenges. Below is extracts of our last conversation on September 12, 2018.

Please note that all relevant comments will be posted. We can only grow by each other’s help. I extend my invitation to share your expert knowledge within our community. I will then link your name (on comment) to you LinkedIn profile as appreciation – if you want so.

Meeting Notes:

  • How to manage International Projects with distributed teams:
    One of our attendees has experience managing projects with distributed team members (in Grenoble, Singapore and California). Due to the time-zone difference, each team used to do their tasks and pass to the next team. Tasks then distributed to the last team to deliver their committed milestone. The team was working round-the-clock for about a month and the milestone accomplished milestone. Hands-off to other teams done using available technologies (email, teleconferences, shared folders, etc.) Collaboration was mainly engineer-to-engineer. Performance was based on work-packages.

    As per International projects, other important considerations are the settings where teams are performing, their laws and regulation, tools and techniques, information / communication channels, and information containment that will affect the success of Centers of Excellence (AKA PMO)!

  • How people deal with dependencies:
    Recalling the materials of Managing International Projects course, many matters become dependencies, including regulatory laws (Export/Import, tariffs, Intellectual Property laws, etc.), communication barriers, time differences, cultural diversities, and so forth. Managing any International project or program involves numerous dependencies, each require specific resolution, mitigation, (risk) transfer, and more!At time this would be like dependencies from hell! (As an example, one was talking about a project when two-weeks before the release, government changed almost everything regulatory, causing disorders in release!)

    There are dependencies where PMOs (or a Center of Excellence) can have influential authority, such as requests delegations, approval (signature) procedure, reporting pyramid, etc. Having an in-country experts (as in-house or sub-contractors) is another way of settling dependencies. Local experts are particularly important in synchronizing actions among various in-bound entities that would help time, language, cultural disparities.

    Time and sensitive functional dependencies; especially when dealing with modular (hardware-software) product development, require higher degree of coordination to reduce task-delivery delays. Utilizing available coordination and team-based technologies helps resolving dependencies as well.

    Conflicting dependencies may result from hidden and / or incorrect assumptions (or agendas), both from the management as well as business needs (resource, objectives, etc.) These may be due to management style / variance, and organizational directions when the top-down resolution becomes the best remedy. Another conflict may arise due to technical or scientific differences that would be easier to be resolved by engineering team, especially if the team is collocated.

  • How to manage real time project status:
    Projects and programs status can be viewed using various tools, dashboards, and technologies like Jira, Confluence, Smartsheet, Trello, Sharepoint, Wiki, MS-Teams & Planners, etc. However, we shall know the capabilities and limitations of each tools used. At times, senior leaders may even create a summary if their dashboards for ease of communications. Frequency of delivery of reports on high level milestone, tasks (and their stages), dependencies, issues, and fixes can be achieved via several means. These are all based on the maturity of organization, tools used, communication channels, etc. Senior PMO leaders might have to anticipate status-reporting of various concurrent projects. The reports are usually in consolidated form for upper management use in timely manner; even if projects are being handled by other owners (Scrum, or any Agile variation).
Please share your remarks, or post your questions. Engage with our PPM community.
I would like to invite you to engage with us at our next meeting. Please check out PMI Silicon Valley chapter events for more information.
I also invite you to contact and post your topic of interest at www.SVProjectManagement.com.
April 10, 2018

PMO as change agent!

Category: Agile, Management, PMO, Program Management, Project Management — David @ 5:44 pm

Agile PMO as Change Agent

I wonder what the challenges of PMO and (Agile) change management are! Some of our experienced PMO leaders think that one failure of (Agile) change management is to couple scrum master and project managers responsibilities into one role! Most of practitioners confess this as a major challenge of Agile transformation in organizations. A project manager is usually responsible for all aspects of the project; planning, scope, schedules, staffing, budget, etc. At the extreme end some project managers are even responsible for Profit and Loss (P&L)! Scrum master is a tactical (coaching) role to increase value creation of the team while training them to become a unit that creates value streams. Scrum master is a servant leader who leads by example. On the other hand, a product owner become the product’s visionary (for goal setting), with some responsibilities of a product manager.

With almost the same catch-all, the responsibilities of a program manager (in some instances) are blurred! In most enterprises project managers climb the ladder of their career, being promoted within their department. They are then asked to handle other aspects of their function, and hence are called program managers!

Agile on the other hand is the mindset, it is a way of doing things, it is not a process or set rules to do things. Agile is not bound to a given process or set of activities, rather it is a way of life! We learn if and when we do something; learn from our failure and use the lessons-learned on our next approach, and this has been how human grows old.

The PMO on the other hand has to decide and propagate the direction of programs. Some (of our) practice indicates that in certain organizations senior (and executive) mangers have high level view of how events go through their organization, while each of sub-mangers know how to handle their responsibilities in their area. Then they (the sub-managers) too, do not know how (exactly) matters move through the company! Hence the PMO shall come up with the philosophy, tools and directions to direct PMs to execute their assignments using ways that they succeed. Dysfunctions apart, the role of a PM is to be “in charge” of the (success of) project; planning, staffing, budgeting, tasks, etc. The scope of “in charge” in many cases does not include P&L, or the business success (or leadership). PMO, even though a bit clouded, is the overall owner of successful processes, tools, metrics, guidance, and practices of projects in different area and expertise. These obligations enforces PMO members to utilize any framework that leads to success. Consequently PMO members in general define how PMO (at least in a given organization) is reputed. From enterprise level - with many concurrent projects of various technical and business nature, PMO members define and lead organizational value creation processes, thus we shall incorporate re-usability and scalability of “lean Agile mindset” and promote it as a cultural change towards triumph.

Upward and Forward,
David Bakhtnia

September 22, 2016

PMI-way of maneuvering challenges of complex projects!

Category: Agile, Management, PMO, Program Management, Project Management — David @ 6:35 pm

We are getting close to 2016 Symposium of PMI in Silicon Valley. A closer look at the speakers and topics (available at PMISV website) portrays real benefits of attending the Symposium. Online search of professional gatherings indicates that PMI chapters hold a high number of symposiums, seminars and conferences with high number of attendees. That’s no surprise as you could see the evidence from the number and quality of speakers at 2016 Symposium of PMISV. 24 keynotes and speakers sharing their experience to overcome challenges and risks in projects; the collective knowledge that cannot be easily grouped together and would require a few graduate-level course to address the issues they resolved.

From risk leadership to addressing possible threats in the design phase, from KISS to dealing with uncertainty while keeping all manners cool, we will hear about selection of challenges with variable ambiguities posing daunting risks and causing projects failure! As the opening keynote, Nick will take an ironic look at risks and its various forms that we’ll face everywhere on our modern-days projects. Other speakers will share their first-hand encounters of challenges in their practices including defies of value-driven organizations, acting fast regarding risk and strategic risk management, dealing with changes and challenges of lean methods, risks of organizational agility, surprises ahead and managing uncertainties. First day’s folding keynote, Richard will share his unique skills of turning risks to values of a mega-project of California Bay Bridge project. Second day starts with Gavin’s KISS method of risk management, following with other speakers sharing their experience regarding QA/QC and critical risk management, schedule and process challenges, dealing with complex risks and the power of communications. Symposium closing keynote will explores the catalytic mechanism when delivering results in projects.

Looking at the quality of shared knowledge I wonder if there is any educational institution providing this wealth of information in such a short time! We have read and heard about risk management and how to identify, analyze, register, and apply appropriate control to “risks”. Yet, knowing first-hand application of risk control in complex projects are not easily found in publications. I personally have the pleasure of idea sharing with a few of the speakers via for instance, assisting Tom Kendrick with a variety of PMI-SV activities and communicating with Joel Bancroft-Connors regarding agile/scrum related topics in the past meetings and professional gatherings.

I am looking forward to seeing many of my colleagues at 2016 Symposium of PMI-Silicon Valley.

A few benefits of attending professional symposiums:

* Online search on benefits of attending professional symposiums/seminars results in:
* To expand skills, learn more about the work, discover industry specific trends and knowledge
* learn from the experiences of your peers, and about valuable resources
* Renew excitement about the work you do while applying new approaches
* Develop ideas that can be implement in your business or career
* Make (new) connections, meet thought-leaders within the industry, share and expand ideas
* Get out of Dodge, show commitment to your profession, find prospects to give back ,and just have fun
* Gain insights and ideas that you can use to establish/increase your credibility and expertise
* Visit interesting new locations where the conference is being held
* Connect with sponsors and other supporters of the conference
* See competitors, learn more about competitive edge, and discover professional strengths/weaknesses
* Meet with and market to potential customers/clients, and study various market needs

September 14, 2014

What is a SCRUM – once again!

Category: CSM, Kanban, Management, PMO, Program Management, Project Management, SCPO, Scrum — David @ 5:57 pm

This is a question that some project and program managers ask often-times! Not just probing its verbatim meaning, but for its real-life significance and value. Is Agile framework specific for software or it can also be used in other types of projects like hardware and construction?

Let’s first recall Agile Manifesto posted on the “Agilemanifesto” website that I have also included at the end of this entry. Even though we all have heard about Agile framework’s rapid / sustainable development, customer-driven, lightweight, competitive advantage, iterative, yet simplicity approaches towards development, I would like to add a few more points! Scrum however, is a special implementation of Agile as short sprints (of actions) to iteratively define-implement-test work cycles or time-boxed team efforts. One thing most people agree is that sprints have deliverables that might not be the end-product! I know many experienced managers who have used Agile in completely nontechnical environments such as hydroelectric smart meter implementations, change management, medical device hardware sub-systems, and other related projects. They all claim they promptly create their teams, make lists (of requirements, etc.), prioritize the action items, flow their planned efforts collaboratively, produce planned deliverables, and iteratively handle next sprint in their list.

However and beyond regular philosophies and proven practical norms, Agile method of managing is more like a mindset to me than the process itself. Many scholars have dug up how human aspects impressed Agile framework, how behavioral-based project management applies to successful delivery, how to improve organizational success Agile-way, and how VUCA is used in emerging ideas of strategic leadership development, even at times of change . We can easily quote the adoption information curve when referring to the adoption of technology and ideas by a population. But when it comes to Agile change adoption, we mostly address the indirect changes (process) rather than understanding the human nature, resistance to change, improved substitutes, and continuous improvements!

I think besides the technique, Agile addresses the mind-set of how to collaboratively achieve a task (or a project) in a flat level among team members where everyone (from customers, to product owners, managers, developers, and implementers) work towards common goals in an iterative progression. Agile is more like conviction to the concept of the crowd (or scrum team) working towards continuous achievements! In this practice all players shall commit to the crowd strength, in a coordinated and collaborative manner.

As per the nature of its applicability, I have seen managers who successfully applied Agile process to technical and nontechnical projects, as well as pure hardware and even construction based projects. We all have heard about “Water-Scrum-Fall” where experienced leaders merge two distinct frameworks to plan, execute, and produce their needed result in a hybrid way.

AGILE MANIFESTO:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’ competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

November 11, 2013

Water-Scrum-Fall

Category: Management — David @ 7:47 pm

The first time I heard the “water-scrum-fall” term was at PMI-SV Annual Symposium of 2013 at a presentation provided by Roger Kent with the heading of “Waterfagile or Agilefall? Rethinking Knowledge-Work Process Model.” Quite frankly I have mixed the two methodologies – whenever a mixture suited my project. But what does it really mean? This topic came up at our PMISV meetings members putting light on its definition. Below are extracts from our conversation at Mountain View breakfast meeting. I have also added a few points expressed by our members attending PMISV-job search meeting on February 4th, 2013.

A hybrid of “Waterfall” and “Agile / Scrum” methodologies means that you are in-between waterfall or agile. Hybrid solutions work well during the transition period. An example is when tests were all paper based. Then we had a mixture of multiple choice tests that were partially computer based, with paper backup. That is a hybrid model of testing in both digital as well paper-based methods. Now there are organizations that provide computer-based tests only; such as Prometric. Another example is hybrid automobiles; our infrastructure (or even our transportation dependencies / habit) is not ready to fully adapt our transportation into electric power. Yet we are using both gasoline based as well as electric powered automobiles. This is because our transportation industry is in a transition process. However, when electric powered automobiles are well accepted and when we create supporting infrastructure for this model, we will move out of the hybrid mode and fully adopt to electric cars. Going back to water-scrum-fall, some are comfortable with waterfall method, and experience some better results using agile practice. Yet they implement portions of each during their process. Most of our top 500 enterprises have used waterfall for years and decades. Yet their experienced leaders observe better results using Agile and Scrum; hence they use a hybrid model to successfully oversee their projects and portfolios.

A myth of agile is that the final result of our project is fuzzy! That is not true. We just manage the process; including customer engagement from the beginning, so that we have more successful projects -a process in which the customer’s expectations are fully integrated into the product. However, agile methodology works where it is proven to work. We still use waterfall with all its maturity in our large and small projects as we have decades of documented processes using waterfall, like most construction projects. On the other hand, an IT infrastructure project like a data center upgrade / consolidation project could have a waterfall planning with scrum method of roll-out – hybrid model!

I would like to open a question to my readers: what about hardware, or a mix of hardware-software projects? Would be better to stick to waterfall, use agile, or come up with some sort of water-scrum-fall?

Disclaimer: This is an extracts from PMI-Silicon Valley Chapter’s group meetings held regularly in Mountain View and Sunnyvale, California. Many thanks to active participants of our meetings:

Carol Blanchar, Soheil Bouzari, Roberto Bruce, Katie Creegan, Karen Ferguson, Ron Green, Michael Jones, Nathan King, Chris Munson, Scott Petersen, Scott Spetter, Brian Wanner, Ray Williams, Terry Archuleta, David Bakhtnia, Sumadhi Lourduswamy, Melissa Pflum, T. Mallie Brathwaite, Paul Diamond, Raj Kamdar, Valentine Miller, J. Lynn Stuart, Kevin Thompson, Anup Deshpande, Wendy Tsoi, Carl Angotti, and Steve Deffley.

August 12, 2013

Cover Letters and their usefulness

Category: Management — David @ 2:38 pm

As I promised in our today’s breakfast meeting, below is the blog about “Cover Letters” that we talked in our last week’s meeting. I know that I am a week behind posting about our last meeting; quite frankly I have been working and networking about 15 hours a week lately - so I finished this short note last night.

This is another session of our “job search breakfast” group meeting of PMI Silicon Valley chapter. We explored the reason behind including cover letters when applying for a technical / management position.

In my opinion, I am wondering how good we could model “human nature” and behavior! Even when applying number-crunching and numerical analysis on human behavior, one cannot get an ample picture on how better approach to any particular action! Everyone is different. However, when applying for a professional position, the size of the company and how they have been posting jobs (online or otherwise), the rationale behind their processes (if we know about), positions’ requirements, HR policies, and many other factors will play roles with regards to sending a cover letter along with a resume, or not to send any! I think the best is responding to a given job opening based on our personal experience, and hoping to land an interview. After all, sending a resume and associated cover letter is to have an interview. One manager may not read a cover letter, yet be swift in responding to follow up emails!

Noting that cover letter is one of deliverables, it’s a good idea to introduce ourselves up front to the prospect employee and make the cover letter like a sales tool. It is helpful to including our sales pitch on top, and treat cover letters like a business communication letter; something like a short dashboard of our knowledge aligned with the requirements. Resumes include the most detailed aspects of our professional expertise, and it usually takes months to polish and fine-tune. On the other hand, cover letters are composed fast; probably a few hours before sending them to an available position. Another idea that was circulated among our attendees was to address 5-top requirements of the position in the cover letters. However, hand-carried cover letters and resumes to the hiring managers have the best results. Identifying an insider and making sure that hiring manager could have a copy of the resume makes the biggest impact.

Other considerations such as styling, font face-size, stationary choice, and such are less important, yet keeping them consistent with the style used in resume is a good approach. However, referencing the salary requirements or any political / faith related concerns, and non-relevant points are strongly discouraged. Make sure that cover letters do not have any spelling error, and keeping them below 3000 characters make them more appealing. Keeping track of the resumes and cover letters that are sent out are another important factor. After all, it is a good idea to have a reference point to requirements of a specific position for which an application is sent!

Online references regarding composition of effective cover letters are in Abundance. Yet our group suggested frequent visits to other networking activities for effective job hunting. Some of the most successful network building groups (at least in the San Francisco Bay Area) are:
PMI-Silicon Valley chapter, our chapter’s Workshops, and some meet up gatherings in your area (such as Agile meet up, Big Data Analytics, etc.) NOTE that by attending these meeting you would get familiar with different vocabularies of the marketplace, as well as expanding your network of professionals you know!

Rise and Shine,
David

This is an extract from PMI-Silicon Valley Chapter’s Job Seeking group meeting in Sunnyvale, California. Some of the participants below are technical managers and members of PMISV:

Azeez ChollampatChris MunsonDavid BakhtniaDavid GazaveGary A JohnsonMichael MellengerRay WilliamsScott E PetersenScott Spetter, and Terry Archuleta.

July 17, 2013

How to bring Agile to other departments; Marketing, Sales, Support, etc.

Category: Management — David @ 6:53 pm

It is a daunting task to convince other departmental executives to coordinate their departments’ projects with the rest of organization using Agile methodology! This was actually a question brought up by a colleague at one of our PMI-SV chapter meetings. Below are some of responses from the leading managers attending our meeting;

  • We shall think in Agile methodology before we buy-in to it! In other words, managers shall think in incremental changes by the team leading to the final product.
  • Expectations of executives must be tuned with Agile mindset.
  • Customers must also be communicated to accept Agile methodology; incremental updates, accepting increments, and proceed this iteration till the end of project / product.
  • Managers need to know that there is no UAT (User Acceptance Test) using Agile methodology.
  • All departments’ team members shall be familiar with Agile methodology.
  • Other departments’ managers and executives must accept that there would be no date commitment for intermediate processes. However, a tentative end-date can be set forth.
  • Drive priorities as set in requirements and proceed with “Stories”.
  • Only commit to what is visible to you (that can be delivered incrementally).
  • Agile is a value-driven process that depends on the value of what is set to be done. The value is known or set by the customers and stakeholders; usually using 20-80 rule (i.e. 20% of requirements will drive 80% of the bulk of the product). These are end user values that are set and delivered incrementally.
  • Agile will use “progressive elaboration” of products and end user results. However, how customers would have end results depends on progressive elaboration and incremental delivery of needs. This is the (Agile) process that shall be clearly communicated to all parties involved.
  • Other time-dependent actions and revenue-recognition event (such as Press Releases) can be addressed depend on the cut-off date set forth at the beginning of the process. However, delivery of requirements shall proceed incrementally till the set-date.
  • Important requirement (within the 20% set) shall be scheduled within the stories and delivered by the set date. All other requirements (within 80% set) are set to be delivered incrementally as the project advances.

More information regarding upcoming classes and trainings in San Jose area:
PMI-ACP Exam Prep Course (3 Days) at PMI – San Francisco Bay Area Chapter:
– Instructor: Anup Deshpande, August 3, 2013 @ 8:30 am – 5:00 pm

Anup also offers training for individuals as well as corporate teams.

Please visit PMI- Silicon Valley chapter website for more information about different activities of PMI - Silicon Valley chapter.

Up-ward and On-ward,
David