top of page
  • Writer's pictureChristabel Misiko

Top Four Challenges When Transitioning from Traditional to Software Project Management

We are proud to host guest blogger Christabel Misiko. Christabel has led multiple client projects for us, and we were impressed with how quickly she was able to shift from a resume of successful construction projects to Agile software development roles. She is always up for a challenge, including her first blog post. Take it away, Christabel!


------------------------------------------------------------------------


Many project management skills are applicable across any industry - planning, organization, leadership, communication, etc. My experience transitioning from construction to software projects, however, presented a number of obstacles that required new tools and techniques in order to deliver successful project outcomes. Here are four of the top challenges I faced, and the solutions that have helped me to both serve my project teams better and develop into a more well-rounded project manager.


Challenge #1 - Pace of Change

Software projects are quite dynamic and often are open to changes in scope, timelines, and requirements even late in the process. In fact, an Agile approach encourages this change. This is the opposite of construction projects, which typically follow the waterfall methodology. Any changes in scope and or timelines are almost impossible to implement without major impacts.


Solution

At first, I had a hard time being flexible and adaptable to these changes - I was used to the client expecting me to prevent and/or reduce change, not encourage it. But after a while I adjusted and looked forward to these changes because our main goal was customer satisfaction. Scope creep can still be a danger when running Agile software development for a client, so just make sure you’re in constant communication with your team; which leads me to my next challenge…


Challenge #2 - Increased Stakeholder Interactions

During my tenure as a construction project manager, we had scheduled meetings with the primary stakeholders once every 3 months to touch base and discuss any challenges. They expected us to simply keep the project on track and only report on major deviations.


However, in software project management we have regular meetings with the customer to discuss user personas, customer journeys, wireframe reviews, software demos, etc. These interactions are typically remote (oftentimes with a project team that is located around the globe) and can take place daily.


Solution

At first, I felt like the meetings were too many and took up a lot of time - but eventually I realized that most of these meetings were more like working sessions, with each functional area of the team collaborating to build a better product. These regularly scheduled meetings also increase accountability, which in turn fosters trust.


Challenge #3: From Manager to Servant Leader

This is not really a problem but an advantage. Working with the software development teams has been such a good experience for me because they are self-organizing. They take initiative to identify the work that needs to be done, prioritize the tasks and manage the timelines. Because the team is structured this way, it allows me to be the best servant leader that I can be. I can anticipate their needs and remove any roadblocks preventing them from doing their work to the best of their ability. I look for potential issues and facilitate conversations between team members and the client as needed.

In comparison, as a construction project manager I had to plan the work, assign tasks to the teams, and follow up to ensure the work is being implemented.


Challenge #4: Flipping the Iron Triangle Upside Down

The project timeline for software projects is difficult to determine from the start and it is susceptible to change mostly because of the dynamic nature of the projects - as I mentioned above, Agile projects welcome changes even at the end of the project.


In contrast, in traditional waterfall project management a concrete project plan is created at the very beginning and scope changes are not allowed (or at least very costly) during the implementation phase. This article provides a helpful summary of the difference in perspective.


Solution

I discovered that the best approach to this challenge is to use a combination of the two techniques - develop a high-level product roadmap towards the beginning of the project, including the project team’s best estimates based on the available data. However, keep the roadmap flexible and don’t be afraid to adjust it as changes to the scope are made. Thanks to the increased stakeholder communications I mentioned, you can make sure that the client is always aware of where the project stands.


Conclusion

Software is everywhere these days! I’m glad that I challenged myself to learn new skills and discover new ways to better serve my project teams. If you are looking to do the same, the above tips can help to make your transition smoother.


About the Author


Christabel Misiko, PMP

Christabel has a combined eleven years experience in both construction and software project management. She has a proven track record of successfully managing complex projects, and brings leadership and innovation to the table. Her vision, drive and intellectual depth help to secure project results under pressure.





Article preview image by Nubelson Fernandes on Unsplash


bottom of page