StrAIT Blogging

Posts Tagged ‘Project Team’

I have been deep in the methodology evaluation business as of late. Our current methodology is our own SLR methodology. It is intended to be used to assess the client’s business processes, specify changes that are needed and map the client’s IT architecture to their revised business processes. Even though it is partly based on the RUP methodology the iterative nature of RUP was replaced with the notion of layers, i.e., first get the most out of what the client already has, then, if needed, shop for commercial software to fill in the holes and finally to develop custom code to fill in any needs that cannot be addressed by the first two “layers”. We also look at outsourcing as an alternate approach. Therefore, SLR will generate some number of software related projects that have to be managed together.

Until recently, the preferred approach for project management of those resulting smaller projects has been a traditional “waterfall” approach as described here. That approach is fairly rigid and top-heavy but does work well for non-IT centric projects. However, since we intend to deliver work in a lean and fast manner, we needed to pick an additional project management approach that is more aligned with the rest of our business. That led to a shopping trip.

There are many available techniques. We needed to stick to options which have broad acceptance. That narrows down the list to Prince2 (UK) and PMBOK (US) for “waterfall” approaches. Scrum (US) and DSDM (UK) for leaner “agile” project management. The newest version of the DSDM methodology is called Atern. All of these options have proven track records and would be safe approaches. However, we already have a waterfall approach so our focus was just on the lean approaches. It’s important to remember the environment in which we will be working. We will be using this approach with teams made up of the client’s resources, our resources, possibly vendor and/or client business partner resources. The projects will probably have a strong software focus but some may not. We have to handle both. Most projects will probably not be developing custom software but some will. We have to handle both of these types as well.

While both Scrum and DSDM Atern will handle our software development needs, Atern will handle the non-software development projects much more easily and be more at home in more “corporate” environments. When I say corporate environments I mean any client environment where the delegation of significant business decisions to empowered teams is a challenge for the client’s leadership. That’s especially true if the team contains significant external resources, like consultants. Atern is a little more prescriptive in nature. There is a little more structure and definition than Scrum. It’s a little easier to formalize change control with Atern. These things are important if the methodology is to be acceptable to client leadership whose neck is on the line for the project’s success. I know how that feels first hand and it’s a big part of our decision process.

Both Scrum and Atern can be compared to more traditional techniques by the diagram below. Essentially what that diagram is saying is with traditional techniques, if you get into a bind with the schedule you can add resources or give the project more time. In the lean approaches, if you get into a bind with the schedule you decide which deliverables, i.e., features or capabilities, that can be delayed to a future release or version of the project’s products. That works in a software centric project but not so much if you’re building a bridge or building.

Scrum is best suited for software companies which have their own dedicated teams of experienced developers that just do software development for a living. It is very focused on that development environment and is much harder to tweak to fit our needs. However, one dilemma is that Scrum knowledgeable resources and training are much easier to find in the US. DSDM Atern is established in the UK and many other countries but it’s almost unknown here. Fortunately, with the pervasive nature of the Internet that’s not the problem it used to be. It’s still a risk but a small, acceptable one.

Atern will be fully embedded in our SLR approach shortly. We believe this addition will add value to our client’s and their projects. Atern is designed to work with the waterfall methodologies so we will continue to use the more traditional approaches where they make sense. If anyone has contacts at the DSDM Consortium, let them know that they need to establish more of a North American presence. They just need to follow the path that ITIL (also from the UK) has taken.

Thanks for stopping by. I hope this post was valuable for you. See you next time…

Bookmark It

Hide Sites

All business process related projects require some form of team to execute the work. Even for small companies with very informal and centralized leadership, BPI teams exist. They may not be formal but to improve their business processes they need a diverse skills inventory to look at the challenge from multiple points of view. The structure of those teams is extremely important. Insuring the appropriate mix of skills needs to be carefully managed by the company’s leadership to include the perspectives of business operations, information technology, staff functions and external stakeholders. Those external stakeholders may not participate the same way or to the same extent but the needs of customers, vendors and supply chain partners need to be included.

Historically, many business process improvement (BPI) projects fail to sustain their initial gains over the long term. Typically, this happens when the key resources needed to sustain your BPI benefits are overwhelmed by the crush of daily, urgent tasks. Over time, the automated part of the business practices may stay in place but the behavior of the people changes. To address this StrAIT Advisors recommends:

• Create a collaborative environment
  

Create a site on your company’s network (portal or something similar) where team members can collaborate, collect new ideas and monitor BPI success. Examples of useful tools are Microsoft SharePoint, Microsoft Groove, IBM (Lotus) Notes/Domino and Oracle Beehive.

• Project team becomes a business process competency center
  

Keep your team focused, even after the project is over. Put some level of accountability in their performance plans to spend a portion of their time managing and collaborating on your business processes from a companywide perspective. Remember it is possible to optimize individual departments but sub-optimize the company as a whole.

• Team leader is on the COO succession plan
  

This is often overlooked. Your business processes are the lifeblood of your company. The Chief Operating Officer (COO) or equivalent has the primary responsibility for making sure all the wheels keep turning smoothly. The person responsible for your company’s business process “think tank” will gain a wider perspective on how your business works, reinforcing the experiences that put them on that succession plan in the first place.

Bookmark It

Hide Sites