Velociteach PM Poster - Observations

Velociteach created this excellent Project Management-related poster, talking about the gap between what users say they want, what they really want, what's sold, what's delivered, what's paid for, and what's supported. Are things really this bad? From experience on many a large project I would say they are.

Some Current Problems in Projects Today

This poster hammers home the concept that stated requirements have to be well-linked to what's delivered, a concept that has been emphasized for quite some time in software development camps as a reaction to "waterfall" type project management. If you're not familiar, waterfall is a "command-and-control" concept of PM where everyone marches lock step through phases, changing phases when the documents are signed off. That might sound comfortable to people who are not detail-oriented enough to really understand what is going on, but the reality is always messier. Other approaches such as or stemming from "Agile" or "Lean" software development, help keep the focus on what's valuable to the customer, and avoid meaningless rounds of documentation and signoff. Note, I did not say those approaches advocate not documenting at all, because that does not appear to be the case.

I was the Japan-based PM for an ERP implementation, where the head of the PMO at my client generally encouraged the use of more Agile methods. We never talked about Agile and what it meant per se, but recently studying Agile for how it might help me manage non-software development projects or general projects, I can see similarities between what's in the Agile Manifesto and Agile Principles, to what we actually did on the project.

One thing that we did which was rather too "waterfall" however, was an attempt to document all the user requirements up front, in a huge list. This quickly got unmanageable partly because we were trying to do requirements this way, with users inexperienced in ERP implementations, and partly because we were using email as a collaboration tool, which was a mistake as well. Thinking about that, users would have had a terrible time trying to remember what they said, in requirements meetings many months back, in specification review sessions. Adding to that the need for translation and interpretation services, it's a wonder we went live as successfully as we did. An attestation to having the same developers and coordinators involved the whole way through, and just general tenacity, if you ask me.

What to Do About It

In summary, my current feeling about what to do is the following:

• Though Email has obvious benefits and applications, attempting to collaborate in Email is not the right approach or, dare I say, any project. Instead, use a system like TargetProcess, LiquidPlanner, Unfuddle, MyIntervals or even BaseCamp.
• Use a V-shaped project process, to link user requirements to user acceptance tests, designs to design validations and so on, so that there is a check and balance in your process. Make it easy for users to see the link between what they asked for, and what was done in the end.
• Poorly-done Agile is just as ineffective as Waterfall, so if you are going to implement different methods, make sure they fit and that you do it skillfully so the whole entity supports it. Don't use Agile as an excuse to be lazy. In fact, Agile requires even more discipline in the team.

The jury is still out for me what the "best" method is and what the best collaboration software is, but I have taken my time to understand methods besides waterfall, and am beginning to apply them in practice. I will post here about my experiences from time to time. I hope you Enjoy this.

Clarify Colleagues' Knowledge - Consultative Management

In consulting or consultative management, I strongly feel that it's important to make an extra effort to clarify your colleagues' knowledge, to assist them in their job.

During a recent Sarbanes Oxley project, my non-technical colleagues were discussing the technical topics of Windows profiles and disk permissions interchangeably. Non-technical folks' eyes usually glaze over when listening to someone in tech drone on about the details so it's never a good idea to overload with too much info, but I think a bit more information in some cases is beneficial. Specifically, this time I explained that NT profiles by default, govern what "rights" you have on your local computer, storing things like desktop icons, printer info, internet bookmarks or favorites, email configuration, help configuration and so on, and, that the sys admin can make central settings that limit what users can do on their computers.

In this way, profiles are rather application centric. For example, a sys admin can say "group X cannot use the command prompt" and so on. I emphasized that to set up profiles would take some planning, as they are very powerful but complex to plan for. Setting one thing can break others, so the subject should not be taken lightly. In terms of file and folder security, on the other hand, I explained that Windows NT and other NT-based servers (Windows 2000, Windows 2003) use a disk "file system" called "NTFS" which both enables and governs how sys admins can set security for files and folders. Further, PC workstations based on NT - NT 4, Windows 2000, Windows XP - all allow use of NTFS, so the same rules apply to PCs and laptops running those OSs.

For example, if you have a folder x:\finance\private which contains a bunch of sensitive Excel files, you can set up the folder as such:

System Admins: Full
Backup System: Full
Finance Management: Change
Finance Group: Read
Some-Other Group: No Access

... and so on. There are many other points to go over about how sys admins can use user groups to define disk permissions and about how those need to be designed and planned, and other caveats to setting these things up. To summarize, I would stress to:

• Listen more than you speak, but use your expertise to emphasize critical points.
• Maintain an awareness of your audience - avoid "tech speak".
• Actively assist your business colleagues to clarify their business requirements, and try your best to have the technology support those requirements.

Happy consulting!

Digital Practice of Law: On the Spot Training

Digital Practice of Law: On the Spot Training makes a good observation that JIT/JE is "the new thing." I have about 10 years of training experience, and coined the term "ConsulTraining" to describe the type of interaction where the trainer is being asked to arrange the training as the recipient wants it, and deliver it one-on-one with a consultative style.

When the trainer executes JIT/JE or as I call it "ConsulTraining", he or she should remember: To emphasize the value of ConsulTraining, and price it as such. I'd recommend not selling out on this process, which can be very effective for your client. To maintain discipline even in a one-on-one situation. It's easy when you're inexperienced to let this sort of situation get away from you and turn into a Free-For-All. Don't do it. To define and stick to the agenda. If your client wants an on-the-fly change, politely make it known that "this is an agenda change, and we might not be able to cover the important topics of x, y and z. Is that OK with you?" I always write down changes that my clients request, so that when the inevitable instance of forgetfulness comes up, I can tactfully remind. To recommend normal classroom training when you know the curriculum is not suitable for a quickie JIT session.

Five Basic Consulting Steps - ADFIR

I identified five steps for our consulting practice at eSolia, which include Agreement, Discovery, Feedback, Implementation and Recycling. If the consultant takes care to complete each step diligently, he or she will find that the consulting process goes more smoothly, and overall it is better for business.

Agreement: The first step in the consulting process allows us to come to a clear understanding with the client as to what each party wishes to achieve, and how they are going to approach the engagement, working up an equitable engagement agreement document to act as a touch-point throughout the engagement. I think the agreement is best kept simple but thorough enough.

Discovery: Discovery is the bulk of the consulting engagement, where the key dialogue occurs that allows us to act as a catalyst to convince our clients to take action. Here, we identify the problem clearly focussing on both the presenting and root challenges, select problem dimensions to study, pick engagement team members, decide data collection methods, and then collect, filter and summarize the data. Finally, an analysis of the data is performed to prepare for the next step - feeding back to the client. Our job in discovery is to collect then cut.

Feedback: Feedback is the step in which we take the results of the Discovery process, and assertively feed back our recommendations to our client. Here, we create a focused feedback report from our findings, condensing them into relevant actions against challenges our client can control. Our primary goal in Feedback is to work with our client to come to a decision about which actions to take. There are some key phrases here - "assertively feed back", "changes the client can control". I think we should pick a path and feed it back assertively, without flinching, but, the changes you are recommending have to be something the client can do something about.

Implementation: The Implementation step is where we assist our clients in implementing the plans everyone has had a hand in creating. eSolia professionals recognize that this process is not just technical step-by-step execution, but also requires acknowledgement of relationship and commitment changes during the process. To this end, we attempt to create an atmosphere of trust where team members can express their opinions or reservations fully, and in which listening and presenting occur in equal measure.

Recycle: The final step is to perform a "post-mortem" on the engagement to decide if there is anything else that needs solved, whether to extend, recycle or terminate. At this stage, we feel a certain success if our client can solve related problems independently, the next time around.

Happy Consulting!

Client Wants vs. Practicality

I had a discussion about an Important Concept the other day with my German IT colleagues from a client. During their visit to Japan, we were discussing that for good user support, it should not be "I want application X" but rather "I want software that does function X". There's a big difference, and it's important for various situations, and not merely in the context of user support.

Let me give you some background: corporate Information Technology departments usually have to provide support for a fairly large number of applications (I worked with a large one that had over 500 packages to cover), without even considering the possible version-driven variations. Some companies simply decide "whatever the users want, they get" and more so if those users happen to be the lifeblood of the company's profits - for example big-name traders in securities firms or top sales professionals for instance. In my experience though, IT departments have to balance user demands with practicality, and limit the number of applications supported. A firm stance is required within the IT department, and should be presented consistently to the company's users, so that when a user asks for a specific and non-standard application, IT staffers or consultants will automatically begin a process of instead considering, with the user, what function that user needs.

If you're an IT support staffer or consultant with enough experience, you'll probably agree that few of your customers likely have the time, experience or patience to understand the depth to which a solution should be examined prior to implementation. However, looking at it from the receiving end, the fact that users or clients want to dictate their solutions to IT consultants is natural. A CFO somewhere might say - "I want an Sleek!Base database that will let everyone in the corporation to do their expenses." The CFO has diligently researched the issues, and as far as she is aware, Sleek!Base is THE answer.

Assuming you have the backing of the department and a mandate to do so, instead of jumping to the conclusion that "Sleek!Base is the right platform for the job of allowing 40,000 users to do their expenses", there are some important initial actions that the IT staffer or consultant should take:

• If you don't have management backing for this sort of strategy, get it before you enter into negotiations, even ad hoc.
• Leaving any trace of arrogance at the door, explain what the standards are if they exist. IT group standards should be rolled out in a transparent and accessible way, before you can easily make such an argument. "Because I said so" does not work.
• If there are no standards that match the request, be prepared with an business-oriented, non-technical explanation of what actions are normally required. How it will be paid for is a matter which will change for every site.
• Allow the requester's resistance to be voiced, and listen carefully. Address the resistance specifically, and simply allow the debate or argument to occur.

At last, it's important to maintain momentum by following up thoroughly (don't skip steps) with either a standard solution, or a custom one, based on what is agreed.

Thanks for reading.