Podcast: Play in new window | Download
Listen in on the interview I had with Cole Cioran as Projectworld in Moncton approaches on Nov 27th. Cole is the Sr. Director of Research – Application development – Portfolio Management with Info-Tech Research Group and is also the VP of Mentoring with the IIBA Toronto.
If you are attending the conference this would be a great session to attend. There are a lot of great speakers heading to Moncton!
Cole will be presenting on the following topics:
Listen to this 10 minute pre-conference chat.
Show Notes:
- Host: Ron Smith
- Guest Email: ccioran@infotech.com
Audio Attribution:
- license
- title: JENNY’S THEME
- creator: Jason Shaw
- audio source
- changes were not made
- Music: https://www.hooksounds.com
Use the comment section below to comment on the interview.
Want to get more helpful project management insights like this directly in your inbox? Subscribe to the Managing Projects newsletter (see subscribe in right side menu).
Ron is a Project Manager with Chalder Consulting Inc. www.chalder.ca
Linkedin: linkedin.com/in/rondsmith
Check out the contributors page.
Transcription of the Interview
Ron: [00:00:03] This is the Managing Project’s podcast with your host Ron Smith. Join me as I talk with practitioners and the leaders and the role of project management and related topics. Visit ManagingProjects.ca for more information. Cole Cioran is the Senior Director of Research for Application Development Portfolio Management with Infotech Research Group. He is also the V.P. of mentoring with the Toronto IIBA. He’ll be speaking on two different topics at the conference on Monday. The first is thinking outside the project box and the second topic is stop writing user stories and start doing analysis. So without further ado let’s get on to the interview. Welcome Cole.
Cole: [00:00:50] Hello Ron, How are you. Pleasure to speak to you today.
Ron: [00:00:53] Pleasure to speak to you. Pleasure to speak to you. Thanks for joining us today.
Cole: [00:00:57] My pleasure.
Ron: [00:00:58] You’re going to be coming up to Moncton on November 27 and you’re going to be speaking at Project World and BA World that’s happening here. The couple of topics that you’re going to be speaking on. One is entitled thinking outside the project box. I wonder if you would give just a minute to talk about who would be interested in that and kind of wet the whistle, if you will, to see if folks might might want to come hear you on the Twenty-Seventh.
Cole: [00:01:24] I’m glad to Ron. And thanks very much for the invitation to do that. I’m really looking forward to coming to Moncton. I’ve never been to New Brunswick before and so it’s a great opportunity to see other province. So thinking about the project box was born out of a series of advisory experiences I had with members and customers over the last several years. Organizations have been struggling with this. What do they do with all of the work that comes out of project delivery. If you think about working code that agile thinks is so important. It is all very well but ultimately until somebody has use that motive to provide the value that was expected from it when somebody needs support they have to be able to get help if somebody is maintaining that system may understand how it’s going to work. A lot of those project artifacts are actually something that lives on beyond the scope of their project. One of the things that project managers and business analysts and stakeholders in organizations have to realize is that that project has an effect on the organization that last much longer than project close-out. So this is a talk about a disciplined approach to managing the knowledge that comes out of that project life-cycle. When you think about product requirements, you think about designs for systems, you think about all of those things that people need to support maintain deal with and or on and have in their organizations. All of those need to be kept alive or evergreen. In order to ensure that they’re valuable down the road. Just as much as the code is valuable that other information is valuable as well. Agile people often say you dont need to do any documentation – we’re agile. However, the Agile Manifesto doesn’t say there’s no documentation, they just say they value working more than they do comprehensive documentation. And when you consider that the agile movement was born by software developers you’d sort of understand that point of view. The documentation is really just a transitory thing for them that they consume in order to write that code. But the operations teams that all too often end up supporting that code need more than that. And similarly an auditor isn’t going to look at the code. They they don’t care what the code says. They care what decisions you made. And were they the right decisions based on the policies and standards your organization organizations to be run by. So thinking about that the outside the project box really is an approach for organizations to think about how to deliver work more effectively and how to manage that knowledge after a project is done. There are a lot of things you have to think about that are different. Such as what kinds of things you maintain because you don’t need to document everything right. You don’t want to have people writing everything down under the sun just in case someone needs it down the road. You want to be strategic about picking the things that you want to manage for your organization. You have to organize and store in a way that’s still valuable. One of my colleagues loves to say that old paper documentation is like cheap wine. It ages fast and it doesn’t taste very good. This is something you have got to manage as knowledge assets just as much as you manage that code base.
Ron: [00:04:31] Well it’s interesting and I’m seeing that as a trend too where you have these requirements that are being managed at a corporate level so I think this is this is a timely talk. I think it’s a lot of organizations that are that are going through this transition right now.
Cole: [00:04:45] Certainly one of the things I’ve seen at big organizations is if you’re regulated, you need to start doing this. I’ve been brought in to work with quite a few organizations from my mom and pop shops with a handful of analysts in a regulated space to some of the largest banks in North America. This is a critical area impacting organizations all size.
Ron: [00:05:05] It is interesting because if you take a look at the scenario you gave. So you were running an agile project and then you need some documentation to hand to or transition to operations. That is the cycle that we find ourselves in at times. It’s almost like an afterthought. In some cases where operations is about to inherit something and you do still hear that we’re running agile that means I didn’t have to document anything.
Cole: [00:05:36] Well and that means that’s great. All right. Does that mean I don’t have to support anything then?
Ron: [00:05:42] Your second topic you’re going to present on is Stop Writing User Stories and start doing analysis.
Cole: [00:05:53] Right. One of the things that I’ve seen with agile implementations is they can often go off the rails if they lack discipline. So one of the most common things I hear is there’s no requirements in agile. Although if you go to the product owner her page on the scrum.org site you will find that the backlog that the product owner manages is the backlog of requirements that there there’s still this bias towards not writing things down. A lot of companies trying to get by with just maintaining a list of user stories. Problem with that is a user story isn’t a requirement. It’s not even full design as Alster Coburn the fello who invented user stories said. It’s a placeholder for the for a conversation. And the most important thing to happen in a conversation is a series of questions that identify things like the requirements and the business needs and the value you expect to get out of this. And so all of those aspects of the conversation are things that get captured by a team or should get captured by team or appropriately as they go through the whole agile analysis lifecycle. Much like the challenge with documentation we just spoke about how do you manage and maintain that. They are valuable in all the artifacts that you just are actually disposable at the end of a sprint. And as well it should be – because you might have similar users users or have a different perspective on the same users story come up again and again. But the requirements and design that go with it are those valuable knowledge artifacts. And so having a disciplined practice around your agile teams where they analyze what they’re doing using the users there is only a placeholder for that. Right which is what it really should be. That gives them the ability to do better analysis and deliver better solutions as Boston Consulting recently commented… The biggest project failures they’ve seen have been with mature agile implementations with a little or poor knowledge of requirements. And so certainly this is again for business analysts and for product managers who want to manage successful initiatives. You need to do a discipline job in an agile environment of doing that business in houses work to understand what you really need to be delivering and the value it brings.
Ron: [00:08:14] So in terms of notables some of the services that you offer you have a one day intensive session. Can you tell us a little bit about what you do with company there.
Cole: [00:08:23] Yes so this is something I’ve offered as a on the side and I’ve taught training courses around agile analysis. So for instance if organizations are looking to build their business model and capability. I come out and teach them not only how to do business process modeling but how to do business process modeling in the context of a agile team. Which is very different than you would do traditional business process. You don’t want to go away and spend two years documenting all the processes of your organization because by the time you’re done they will have all changed and you can just throw at work in the garbage. The goal is to teach and it’s not just the discipline skills of visual modeling which help them deliver better work but also to show them how to do that context. They don’t become a barrier to delivery. Because that’s very quickly where they are an analyst and get into trouble because they’re agile. People are ready to start developing coding if they’re going to go away for six months and write requirements, it’s not going to help. So you’ve got to work differently in that environment and modeling is a key part of it.
Ron: [00:09:23] Interesting so if you have any favorite tools that you’re working with are tons of them I love.
Cole: [00:09:29] I think there’s really seven types of models that everybody should know how to do they need to know how to do context modeling. That’s a great way to get from. I started business goal to understanding what the stakeholders really need to implement as part of a project. Business process modeling provides that next level of detail that’s really critical for understanding how a solution needs to work particularly in a regulated environment. You have to understand where nonfunctional and regulatory rules all come together to influence how you build your solution. Another area is around UI moc-ups. Good agile practices all over have been using them for years. It’s a good tool for every analyst to know how to use because you want to show people what screens look like. It helps them get a better sense of where you’re going to build. On the more detailed side data models, data flow diagrams, and state diagrams and sequence diagrams are all really essential to blow that context around the user story. And so the trick is to use these tools at the right time in the right places you’re elaborating your use of stories to build the right solution.
Ron: [00:10:37] Well that’s great Cole. You know I’m excited to hear you when you come to Moncton. I wonder what’s the best way for people to get a hold of you to reach you if they wanted to ask you a question or you have a website or an email you like to share.
Cole: [00:10:50] Certainly they can reach out to need the infotech.com Web site my analyst bio and contact information is available there. And the conference itself Infotech is going to be hosting booths and will be available for people to come up to chat with us and learn more about what we do here to help drive better I.T. practice across the whole software delivery lifecycle and application lifecycle.
Ron: [00:11:16] Fantastic. Well the clock is ticking because this whole show is starting in about a week’s time.
Cole: [00:11:24] Well I’m looking to being there so good times and I’m looking forward to meeting him in person.
Ron: [00:11:30] You’ve been listening to the managing project’s podcast. Be sure to visit us on ManagingProjects.ca for sow notes including links to books and resources mentioned. And don’t forget to sign up for e-mail notifications so you’re the first to know about new episodes. You can also follow us on Twitter. At manage_proj. If you enjoy the show please leave a review on iTunes as it helps other people to discover the podcast. Thanks for listening.