Archive for the ‘Project Delivery’ Category

Wrapping Up Timeboxes

In my last post I addressed our decision to use DSDM Atern for the projects generated by an SLR engagement. Now comes the decision on what I call the “engagement architecture”. What this phrase means is what are the tools we will use and how will we use them to actually execute projects. No one tool does everything needed to execute projects in an environment of empowered, collaborative teams executing an iterative methodology. Trust me, I’ve extensively looked for the “silver bullet” application that does it all and could only find several lead bullets and a couple of bronze ones.

We need to remember that we’re also talking about doing projects as consultants working with both our resources and the client’s. That means that the chosen approach must have negligible impact to the client’s IT infrastructure and not commit the client to additional long term recurring costs. When we leave the engagement, we must be able to fold up our tent and take our working environment with us. That certainly isn’t always true but our planning must be based on the most conservative scenarios. The only materials that must be left behind are sufficient documents to support SOX requirements and audits. For any client, the answer is one of three modes.

Mode 1 (primary)

The primary collaborative environment is Microsoft Groove 2007 (soon to be Microsoft SharePoint Workspace 2010). In this mode the client provides a copy of Groove to each team member. Groove functions primarily in a peer to peer architecture but has a server-based architecture available when/if needed. For small teams peer to peer is appropriate and convenient. That approach can definitely scale to larger sizes but at some point a server option may be more appropriate. I know many readers will start to groan at the mention of peer to peer. I have discussed the value of this approach before. A link to that post is here. It fulfills the requirement of leaving no lasting footprint on the client’s IT infrastructure (only user PCs), does not inflict a recurring cost on their business (there is a minimal onetime cost) and definitely provides a flexible collaborative environment for the project team. I will not elaborate on how Groove is used because I don’t want this post to turn into a pitch (it’s already more pitchy than I would like).

The brainstorming and creative component uses MindManager from Mindjet. I have found it to be very useful and its integration to Microsoft’s Office Suite is very beneficial. The use of the Microsoft Office Suite (Word, Excel, PowerPoint, etc.) is assumed. For project schedule management we use the venerable Microsoft Project tool. For the methodology and document control we use Project in a box. We use the client’s storage/portal for archiving project information or we can archive it on our own SharePoint server. The use of all of these tools can be adjusted based on the client’s preferences or the client can just use our default engagement architecture.

Mode 2 (cloud)

Here the primary collaborative environment is one of several cloud-based project management tools. There is a wide assortment of them available and we have a few preferences. But the client’s preferences are what count so we’ll review the options with them and go from there. The reason this is not our primary approach is that I’m not satisfied that all the security “rude surprises” are all know yet for that approach (see this link) and it can inflict a recurring cost on the client. However, it’s all the rage now, very popular and growing. It will mature in time to address all of my concerns. We acknowledge that and will be happy to not fuss too much with the client about it if that’s what they want. The bottom line is that it can work for this requirement.

Mode 3 (whatever)

This is simply the case when the client is a larger, more IT-mature organization and wants to do it their way. If this is their preference we say “yes, sir”, salute and do it their way. This is true of any consultant in the world. We will do the best to adapt the core parts of our approach to that environment to assure of project success. We won’t let the client shoot themselves in the foot (or at least not contribute to it) but we will be adaptable.

In conclusion

We’ve covered a number of tools at a very high level. Each of you has to find the combination that works for you. I believe these approaches work for us and our clients to deliver professional and successful results for each project. If anyone from the DSDM Consortium reads this please harass the Project in a box people to expand their tool from just a document repository to include some of the functionality described above. If anyone from Project in a box reads this please consider yourself harassed.

Thanks for stopping by. See you next time…

Why DSDM Atern?

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…

Project in a box

This post will be short and revolve around a handy new piece of software I’ve come across. I will not try to do a detailed software review. I will focus on the basics and identify my interests. I believe that my interests should be similar to many of my readers. So let’s start with my needs and drivers. While that means talking about StrAIT Advisors offerings, I will make very limited reference to them. A blog post should not be a sales pitch.

My needs focus on project management and a project management office. Our SLR methodology is about using various tools to identify business process and technology improvements for our clients which improve the business IT alignment. The result of that work produces one or more projects. Those projects will have a major software component. That component will consist of making better use of existing client software, purchasing new software and/or some custom software development. There may also be a related project addressing computer or network hardware. The result being multiple technology projects being managed concurrently.

Today we use Microsoft Project for schedule management and we manually manage project documentation. It’s that manual management of documentation for several concurrent projects that is the issue. That approach works fine for a limited number of smaller projects but obviously doesn’t scale well. That brings up the concept of a PMO, or project management office. A PMO is what you need to effectively manage multiple projects. To do that successfully you need a tool to manage all that documentation with an audit trail. Such tools can be large and complex content management systems. StrAIT Advisors doesn’t need that. We need something lighter than a big system but still able to handle a substantial number of documents.

While shopping for such a tool I can across Project in a box from Prosis Solutions, Ltd located northwest of London. There is a free community version for single users. There are also affordable, server-based versions. I tried the community version but quickly bought a server-based version. The free version can use the provided methodologies but cannot create any. I need to be able to build my own and work with others. The screen shot below can represent any version of the product.

This example uses the provided DSDM Atern methodology, which is actually of the most interest to me. I like the ability to include an image with click-able areas, as shown on the left of the screen. Clicking on the image loads the appropriate collection of documents, as show on the right.

The package comes with Prince2, DSDM Atern and some related methodologies. Since Prosis is a UK based company, their primary focus is on Prince2 and DSDM Atern. I’m in the process of adding a PMBOK methodology (from the PMI). Based on my needs, I think that the Atern methodology may be the best suited for StrAIT Advisors. It’s an alternative to Scrum, which gets more press in the US.

I like the version control and audit trail. It seems to be a very adaptable tool. For more detailed information I suggest that you check out their site.

With the links provided in this post you can keep yourself busy and immersed in project management reading for days. Proceed cautiously. However, if you have a need for a very useful and adaptable tool, I suggest that you check out what you can do with Project in a box. I will let you know it goes for me in future posts.

If any Prosis people read this post, please comment on my ramblings and add your thoughts. I’m just starting out with this product and would love to hear more. Your company has been very helpful so far.

Thanks for stopping by. See you next time…

Flat World, Flat Clouds

I was thinking on some of the issues raised in Thomas Friedman’s book “The World is Flat” and what it means to the consulting world and the midsize business world. If you haven’t read this book a link to a summary is provided here. His book is actually divided into two general parts. The first part contains his observations on a globalized economy, social factors, technology and the development of several third world countries. The second part contains his social/political recommendations for the future. I think the first part is very useful. The second part, not so much (big government and big taxes aren’t my cup of tea). This post is directed at U.S. located companies. For those of you not located in the U.S., the logic is much the same.

My concern is the management of intellectual property and projects amid the proliferation of sources of skilled service labor, such as consultants, managers, engineers and software developers. For example, your company may need to develop a new product. If your company is a midsize manufacturing company, it may not have sufficient resources to execute all aspects of converting a good business idea into a mature, profitable production facility. Your company will probably look outside to various sources, both familiar and new, for help and advice. If you apply the observations from “The World is Flat” to all the companies involved with your project, the result can be a complex, interdependent web of knowledge and judgment sources.

Certainly companies deal with that situation today. However, the complexity of such arrangements will grow in the future. Now is the time to plan for how to handle that dilemma. I don’t presume to offer a solution in this short blog post. I can only try to frame the questions and offer some ideas. At least, I hope to get you thinking about this topic.

I need to define the types of service labor and regions that will be relevant to this discussion. First, I categorize service labor into three basic groups, shown in the table below. The table also includes some of the major attributes of each category. The key differentiation between each category is the tightness of the bond between the company and each group. That is determined by the level of involvement in core business processes. The “coreness” of a business process is defined by how integral it is to the value proposition of the company. “Direct” labor will always be direct employees of the company. “Close” labor may not be employees of the company but they will probably seem to be employees to an outside observer. “Packaged” employees will obviously not be employees of the company although their contributions will be considered very valuable. Other categories could also be defined for various levels of closeness to the company but these three will be sufficient to make my point.

There is also a need to define the notion of proximity. Direct labor will mainly be located at one of the company’s locations or a location sanctioned by the company, such as an employee’s home office. Close service labor may be located at the same locations as Direct labor or their employer’s locations. Packaged labor will typically be remote to the company’s locations but available when needed. This type of labor can be located anywhere in the world. Typically they will be located in one of the areas on the global map above colored in red (Note that the color red does not have a political significance, only an ease of visibility significance).

There are also some other terms of significance. You will also need definitions for “outsourcing“, “insourcing“, “offshoring” and “onshoring“. To save time and words, those definitions are provided by their corresponding links. All of these terms apply to the location and accessibility of service labor resources. For example, it is entirely reasonable to talk about outsourcing a business process to a domestic (onshoring) contractor. That service may require “Packaged” service labor requiring a well defined scope of work and contract.

Projects, such as the types discussed above, can require a traditionally managed approach or use a lean, timeboxed approach. For example, if using the lean approach, a timeboxed part of a larger project could be outsourced to an offshore provider of Packaged engineering resources. The customer must then provide a home for all of the intellectual property being generated as the deliverables. A well defined policy and content management system are essential requirements. Fortunately, various tools are already available to fill these needs and more are on the way.

In summary, every company needs to be developing policies and tools for managing the intellectual property produced from multiple, smaller and networked service providers. These providers of skilled service labor can be located almost anywhere in the world. They may be close at hand or at arm’s length. I want to strongly encourage readers from midsized companies to not view this as a problem only for large, multinational corporations. If not now, it will also be your problem in the near future. In future posts, I’ll drill down into these broad ideas and suggest some specific actions. Hopefully, I’ve raised the awareness of those of you who haven’t been thinking about these ideas before now.

Thanks for stopping by. Stay tuned for more…

Structuring your team for BPI sustainability

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.

Archives
Categories