Known as a seasoned agile and cross-functional leader Suma has proven skills in facilitation, product strategy, working with Agile frameworks such as Scrum, SAFe, and Kanban. Currently, a DevOps Institute Ambassador voluntarily contributing to DevOps movement, empowering DevOps Institute community members with SKIL framework to advance the Humans of DevOps with Skills, Knowledge, Ideas & Learning.
She is a certified Project Management. Professional (PMP®) & holds multiple credentials in DevOps such as certified DevOps Leader (DOL)®, and a certified Lean Portfolio Manager, Scrum professional with an MBA (Finance) degree, and engulfed by the continuous learning culture!
- Project and Program Management
- Leadership skills
- Blogging
- Reading
- Browsing online - Upskilling
- Online shopping
MBA Finance degree
With a proven background in Program/Project Management, leading technical and administrative management for end-to-end IT services, I have delivered quality solutions for top organizations in government and civilian sectors. I possess a record of success analyzing operations, then designing and instituting PMO methodologies that improve efficiency and reduce costs. I possess expert skills in planning, monitoring, reporting, resource management, quality, and risk management. I have consistently delivered large scale projects over $10M and upwards on time and budget.
Program Portfolio Management Skills
• 12 plus years’ experience serving as program/portfolio manager for mission-critical efforts that impact multiple organizations.
• Managed multiple concurrent projects and managed teams that ranged in size from 7 to 70 members.
• An advanced leader can read between the lines, pick up on the nuances of the situation, and interpret the data within the proper context.
• Responsible for leading projects through the full system development lifecycle from requirements to implementation. I supported Proposal writing and think tanks.
• Led planning and execution and rolled out of processes such as but not limited to - Intake & demand, risk and issue management, bug life cycle, and staffing capacity model.
• Program Milestone: initiating, planning, executing, UAT, implementing, and post-production maintenance.
• Tracking budget every month to reflect overage vs. underage. Based on that was responsible for creating work packages to offset the budget allocations. Reports were generated to reflect the same for the leadership team.
• Project portfolio controlling: monitoring and evaluating project progress. Extensive experience working with business stakeholders and executives.
• While seeing the big picture and balancing against the day-to-day program management activities focused on realizing the organization’s strategic goals.
• As Program Delivery Manager in a customer-facing role, my experience spans across managing complex systems development that required superior analytical skill, disciplined system thinking, a high degree of planning, and execution, financials, and outcome delivery.
• Subject Matter Expertise (SME) to support and roll-out PMO and EMPO/BTO processes, procedures, and tools within IT and enterprise.
• Passion for collaboration. I spent most of the time communicating, collaborating, and coordinating cross-functionally throughout the organization.
• As IT PMO Program manager, my responsibilities included but not limited to;
o Ensured that the teams supporting organizational priorities delivered the systems on time, within scope, and budget. (40%).
o Matured the project and program management methodologies necessary for effective solution delivery (40%).
o Developed and maintained credible and effective relationships across the organization and with external stakeholders (20%).
Traditional Project Management to Agile Project Management ‘The Transition’.
In today’s fast paced world, Project Management had become one of the strong & most important pillars that help organizations deliver applications with less glitch in their processes. Whatever might be the size, nature of the organization or the software development methodology or practices an organization might be adopting it is becoming increasingly necessary to explore different techniques and latest methods in project management to deliver maximum value to stakeholders.
For the same reason many organizations are moving towards delivering software using agile methods and techniques. While agile methodology in itself is not overly complex, what makes it seem difficult for organizations is the transition to Agile. I certainly don’t want to over simply the resistance you may face in the due course. The resistance is not many folks have worked in Agile environments, hence they feel compelled to stick to what they are most comfortable with – i.e., Traditional approach. Before I share my experiences working with teams / organization transitioning to Agile, let’s look into some difference between these 2 methodologies.
As per the Traditional Project Management Methodology based on PMBOK® guide; it gives an overview of good practices, methods and techniques to use. Traditional project management will require; more detailed planning, a toolkit consisting of good set of processes, practices, procedures, tools and techniques to kick start the project. This methodology will have specific set of folks with specific skills and experiences within software development lifecycle with defined set of phases from inception to closure along with clear set of stage gate deliverables. Of course, the deliverables vary depending on the type of contract a project is on.
Traditional methodology emphasizes on a lot of upfront planning keeping all the above parameters in perspective. The challenge with this approach is there is very little room left to accept any change in requirements which will cause the upfront planning wasted at a later point in time within the SDLC. Besides there is a lot of emphasis on linear processes, comprehensive documentation and formal change management system. In the end, stakeholders / business team has very limited view into what is being built until late into the lifecycle which sometimes resulting in unhappy stakeholders.
In contrast Agile Methodology follows an iterative and incremental development processes which are divided and are called as sprints (2-3 weeks cycle). The methodology is open to change as there is less time spent for upfront planning (except for Sprint 0). The team works against a prioritized list of requirements called product backlot which is based on the business value provided by the Product Owner. Agile software development methodology values as describe in Agile Manifesto are based on;
• Individual and Interactions over processes and tools – Tools and processes are important, but it is even more important to have competent people working together effectively.
• Working Software over comprehensive documentation – Good documentation is always useful to help people understand the software being built and how to use it, but the focus should be on how to build software that is working and not documentation.
• Customer Collaboration over contract negotiations – A contract is necessary to being the project work, but that is not a substitute to working closely with customers to build the software as per their needs.
• Responding to Change over following a plan – having a project plan is important, but it should not be too rigid with no room to accept changes as the technology and/or stakeholders priorities keep changing. It is important that the team should adopt and adapt to change.
Here are some challenges I encountered. I’m sure you’re familiar with many of them;
• Lack of leadership support: Without top leadership support you are unlikely to succeed. At the same time, it is important to focus bottom up especially as the middle management often pursues their own agendas.
• People in the organization are not exposed to Agile: Sharing your vision on how an agile organization will look like will be difficult in such cases as majority of them are not exposed to agile methodology itself.
• Organization supports matrixed or Individual contributors: While transitioning to Agile it is important to think and work as a ‘TEAM’ there is no place for ‘I’.
• ‘Agile Project Manager’ role: This happens when organizations don’t have a clear understanding to differentiate between ‘Project Manager’ and ‘Scrum’ roles. A Scrum Master is not the project manager, and vice versa. Also, when the organizations are ‘doing more with less’.
• Lack of Scrum process and roles clarity: If the organization still believes in traditional methodologies and processes because of which they fail to understand the empirical processes of Scrum. Down side to this is lack of clarity of the 3 key roles (Dev team, Scrum Master and Product Owner) due which resistance is faced.
How to address these challenges?
• Planning for Agile transition or transformation: Just like we plan on projects it is important to ‘Plan’ first. Do some upfront planning with the right set of people, processes, support and tools in place. It is important to plan as you transitioning into Scrum roles and a complete, cross-functional development teams that can take the backlog items all the way to ‘DONE’.
• Acquire Buy-in from top Leadership team: Communicate and engage top leadership team into accepting and promotion transition goals. Discuss with them the benefits of switching to agile and how it will maximize the value of product resulting from the work of development team. Be sure to collaborate and communication with stakeholders / business side while transitioning to agile.
• Provide training and educational opportunities: Agile methodology is different from traditional methodology; hence it is a shift in mind set along with adopting to change. Organizations should conduct training courses and provide learning opportunities for teams so they can handle the change.
• Have a clear timeline for the transition: It is important to have start and finish times for the transition. Make sure to clearly communicate these timelines throughout the organization so everyone is onboard. It is important to stay on track while leaving plenty of time for your teams/ organization to understand agile. At the same time don’t make it too long.
• Allow time to improve and retrospective at multiple levels: Once the organization transitions to agile it is important to provide time to stabilize and improve. While at the same time have retrospectives at frequent levels to ensure that the agile methodology is working as intended or if there are opportunities to improve?
Lastly, transitioning to agile methodology can be challenging endeavor as there is no ‘one-size-fits-all’ approach. It may take several attempts to get it right, but it is important to keep things moving, having an adequate understanding of how these processes, methods and techniques work and most importantly an open mind to adopt & adapt to ‘AGILE TRANSITION’.