21 Apr 2016 » Adventures in PM - Capstone Project
For the past month or so, I've been working on a Coursera specialization in Project Management. The specialization is comprised of 4 courses, the last of which is a capstone project. The capstone project is designed to force students to use and apply what we've learned in the previous 3 courses in a practical setting. Needless to say, it's difficult emulating a practical setting in an online course, so I've gotten the go-ahead from my manager to use an upcoming roadmap item as the basis for my capstone. I can't even begin to explain how exciting that is. I'm only a couple weeks into the capstone project, but I've already learned a number of things about myself, the project, the process, and management.
Project management requires a whole different kind of thinking
I'm a software developer by trade, training, and practice. I know that when I'm developing a new feature, there's a lot of thinking that goes into implementation and how to lay out my code. As a developer, I also have to be aware of technical constraints and do a lot of learning to keep up with best practices. At a high level, there is some overlap between these thoughts and those a project manager would have, but the differences are, as I am currently finding, even greater.
Where development is focused on the implementation details, project management is concerned with the bigger picture. Why are we taking on this endeavour? What are the risks and considerations upfront that we're aware of? What resources are available to us to "get 'er done" in time? What are the successes we want to achieve by completing this project? And how much will that all be affected if a necessary change arises? Some of these questions are posed to developers as well, but the fascinating thing is that the type of answers will be drastically different.
As I'm working on my capstone project, coming up with answers to questions like these, I'm finding myself thinking about the other departments and their involvement in these projects. No longer are these questions just about implementation, but about the entire endeavour of releasing a new feature -- and that's exciting as heck!
Project management is different from product management
... which isn't to say that the two do not share some commonality. There are numerous articles out there that provide answers to the query "difference between project management and product management", and oftentimes business analysts get included in these articles as well. There is good reason to wonder about the overlap between these roles as they focus on similar skills, both interpersonal and management. However, there are some disparities between these roles that should not be ignored or glossed over. I saw an analogy by Derek Morrison that highlights the difference between the two:
“A Project Manager is like a mid-wife -- he/she delivers the baby, hands it over to the mother and moves on. The baby being the product and the mother being the Product Manager.”
Again, there is definitely overlap, but there is a clear separation in the roles that focuses on two concepts: time and context. Projects are inherently temporary; they have a start and end. In managing a project, the context you are dealing with is the project itself -- its objectives, perceived risks, and changing complexities. The product lives on with, ideally, no end in sight. Products are born from the results of projects, and so management of them extends beyond what happens on a project level. Conversely, product managers find the business needs and plant the seeds for projects based on those needs.
Project management entails a lot of documentation
Documentation is important, and this importance spans across multiple disciplines beyond project management. In our case, documentation is the main output of a project manager, aside from the project deliverables themselves. There are a number of documents required for my capstone project: project charter, work breakdown structure, activity sequence diagram, risk management plan, milestone schedules, and many more. Coming from a development background, it's mind-boggling to think that so much documentation is necessary, but I'm finding that as I flesh out the details of my chosen project, these documents are all crucial to the development of the project. In creating these documents, I'm being forced to think and analyze several dimensions of the planning process. These documents also serve as a consistent medium through which ideas can be disseminated.
"But," you exclaim, "there's documentation in development as well! How is this any different?" In essence, it isn't different -- in both instances, information is disseminated in the form of documents, and the nature of these documents is technical. The difference lies in the content and the sheer importance of the documentation. For developers, the world changes so quickly sometimes that documentation goes out of date quickly. This isn't to say that project management documents don't go out of date, but rather that since these documents are the main, tangible output, it's easier to maintain them. In fact, it becomes a core part of your role to update them to facilitate communication. Documentation updates for developers are always going to be second to the code, there's no doubt about it.
I enjoy writing documentation, a lot
I love reading, and though this doesn't always translate into a love for writing, I love writing, too. I've always had a passion for writing fiction, but technical writing is enjoyable in a different way. It feels good to get thoughts, ideas, and details out. In terms of my capstone project, working on each of its deliverables has made me realize just how important documentation is to me. Maybe this stems from my love for reading and writing, but I think there's more to it than that. There's a certain art to technical writing, and though the "technical" descriptor doesn't conjure any particularly romantic or dreamy visions, there's still something to this idea of taking dry, jargony technical terms and making them palatable.
That being said, what is most paramount is my desire to move forward, to get going with this project. So far the deliverables have been incredibly thought-provoking, and my existing view of product features is being flipped on its head. There is more to a project than just the feature it produces, and there are so many moving parts to a project that need to be managed.
Communication is a project's life force
It's a well-known fact that communication is the key to unlocking so much in this world. We all live in our own heads so much of the time, and the only way to break out of there is to communicate. As much as documentation is a part of a project manager's role, communication is even more so. This is something that was mentioned throughout my specialization, but never did it become so clear as when I was drawing up the project charter and exploring what the project objectives were. I touched on this briefly earlier, but communication between people is what keeps the project moving. There's an inherent feedback loop built into the process that isn't called out specifically, but is what facilitates it all. No matter how big or small a project is, there needs to be communication.
I've still got almost an entire month to finish up my deliverables, so stay tuned for future PM musings as I puzzle my way through this capstone. It's been an enjoyable journey so far.
Let me know in the comments or on Twitter if you have any other pearls of project management wisdom.
comments powered by Disqus