February 16, 2008
E-government traditionally refers to the delivery of government information and services online. The web presents governments with cost effective ways to reach out to the public and governments at all levels have placed a wide range of materials on the web from publications to databases. But e-government offers governments the opportunity to listen as well as to speak. I would argue that the full potential of e-government will only truly be realized when the ‘e’ in e-Government stands for ‘engagement’ rather than ‘electronic’.
Email allows citizens to interact with government officials or request information or services. While email is certainly the easiest method of contact, there are other methods that government websites can employ to listen to the public. These include areas to post comments, the use of message boards, and chat rooms. Websites using these features would allow citizens and department members alike to read and respond to others’ comments regarding issues. Survey tools, polls and petitions could be used as could blogs and Wikis.
Citizens bring diverse perspectives and experiences to e-government, and government would benefit from citizen suggestions, complaints, and feedback. Even a simple feature such as a comment form empowers citizens and gives them a voice.
Business has learned to leverage electronic services to create new paradigms with its customers. Self-Service, online order entry and online support are all examples of business shedding expenses in exchange for putting consumer’s in control. Experience from e-businesses shows that the identification of customer needs is an iterative process involving interactions of various forms. Government must learn to do the same and the next wave of e-government must move towards building engagement with the public so that the public use services through new channels, not because they save the government money but because they are more efficient and effective.
The debate over web personalization vs privacy will continue for the foreseeable future. Technology, and the ability to target and respond to an individual’s needs clashes with the individuals right to forbid others from getting too much information about their behavior. Privacy advocates will continue to raise concerns about the use of technologies but once we solve the problem let’s hope that technology will be used to encourage participatiion by citizens rather than simply make existing processes faster or worse spread existing poor ones.
February 13, 2008
In the beginning life was simple: there were Analysts and Developers. Analysts acted as Project Managers if they needed to and Developers provided what administration was needed (system, network, database). What little administration was required was done in a timely manner, in response to the needs of the project. At some point in time a trend towards specialization took over. Suddenly we need Network Administration, Server Administration, Security Administration, Storage Administration, Backup Administration, Database Administration, Deployment Administration and of course the glue that holds it all together Administration Administrators. Today many IT directors in a large corporations are surrounded by an entourage of software administrators all working hard to make them as paranoid as possible about needing their skills.
This fragmentation has had some seriously negative consequences including increased communication, more dependencies, decreased agility, more staff and the ever popular process, procedure and paperwork.
The cost of supporting all these administrative roles has exploded. The upside is that it has created management roles for many. The downside is that it slows project progress. On a daily basis I hear developers cry some form of “WTF” or “I can’t believe this…”.
My view of Database Administrators is polarized. More so than ever before I view databases as an integral part of an automated system. DBAs who understand the details of the database engines and are willing to participate in developing a system are worth their weight in gold. They are in essence developers and an integral part of a development team.
However, there is a special breed of DBAs who have blossomed in large corporations who don’t understand this role. Their authority comes from owning database permissions. They frown at the thought of creating or altering a table. Try “evolving” a physical database design in some organizations. How can you experiment when every change must be justified to a DBA who then will have you wait while they reluctantly schedule the change for you.
Much of the large corporation inefficiency in software development comes from administrators who have been given too much power, and often take up adversarial positions against development teams. This isn’t something that can be fixed easily because there’s often a deeply rooted culture of control and change prevention.
It’s no wonder that so many large corporations outsource their major projects.
March 11, 2007
Developing products is an important part of what Thinknostic is all about. We build commercial software products for our clients as well as develop our own product ideas. The product development process both energizes and invigorates us by encouraging us to use techniques we might not otherwise use and apply disciplines we might not otherwise have.
Creating a new product requires inspiration, innovation and a keen sense of what consumers want. This is where Product Management begins. The term “Product Management” seems to mean different things to different organizations. I like to think of the role as being the primary liaison between the software team, the marketing team and the business team. In many cases the Product Manager may have been recruited from or asked to also lead one or more of those teams and this might explain why the role has no universally accepted definition.
First and foremost the Product Manager is a representative for the products market for all important team decisions. It also involves acting as a liaison between the software team when dealing with customers and acting as a representative of both when dealing with the business and financial side of things.
The Product Managers accountability is to deliver the right product. That means they are trying to delivery maximum value to the customers. The Project Managers accountability is to deliver the product right. That means they will be striving for defect free code, delivered on time and to budget. These roles are co-dependent and their goals should be complementary however there are times when trade-offs need to be negotiated. For example incorporating new features late in the delivery cycle can jeopardize the availability date, destabilize the code or blow the budget. On the other hand not having the feature might mean losing an important customer or missing a new market segment. The most critical part of Product Management is figuring out who your customers are, and what they need.
How we fit Product Management into thinkWRAP
At Thinknostic we aim for commercial quality at prototype speed. This means short release cycles and quick rapid feedback. Neither ours nor our customers budgets are unlimited so our focus must always be on maximizing customer value and that means that our product managers need to be priority setters. They must be very effective at information gathering, synthesis and dissemination so that opportunities to improve consumer value can be quickly assessed, prioritized and communicated to the development team.
There are many aspects of thinkWRAP that make the Product Management discipline even more important. There is a need to get an up-front understanding of the products value as perceived by the consumer, and continually validate and refine that throughout the project. Priorities must be adjusted as our perception of reality evolves. A thinkWRAP project treats completion dates and budgets as fixed unless the business decides otherwise. That makes scope or features the major variable. Deciding which features provide the maximum value requires extensive customer input, experience and sound judgement throughout the project. That is the core responsibility of the Product Manager.
March 11, 2007
I’m starting a new activity: visiting Universities with my oldest son. He’ll be finishing high school this year and is trying to decide where he wants to go to school next year. When I was his age it never occurred to me to visit a school. I felt I could learn everything I needed to learn from a brochure but my son is different from me. He wants to absorb the feel of the campus and have a first-hand look at the facilities before he makes his decision. What will be difficult for me as a parent is knowing when to speak and when not to so that he makes his own decisions.
The when-to-shut-up problem is the same problem that managers encounter when coaching or mentoring at work. When coaching, it’s often much better to allow the coachee to brainstorm, and evaluate their options, rather than imposing the coach’s perspective. Telling people what to do or doing it for them is not coaching. It’s very ackward because coaches and mentors are often chosen for the experience they have. Denying that experience can be difficult to do but sometimes it’s for the best.
In this case my son needs to make his own decisions. He needs to develop the criteria by which he can evaluate his options. I am helping by suggesting a few things, and by asking a few leading questions but I can’t answer those questions for him. Providing my opinions all the time would be imposing my help. So I’ve been working on asking open-ended questions and asking about decision criteria. I have even suggested he develop a budget. Mostly I am practicing at nodding a lot. It’s a little difficult, because I have strong opinions but I’m getting better at it.
If you’re coaching someone, make sure you think about when to speak and when to be quiet. It may not be difficult for you but make a conscious decision for the good of the coaching relationship and for the coachee. It’s worth it in the long run.
March 7, 2007
“The Art of War” was written by Sun Tzu a Chinese General who lived over 2500 years ago. This book has for very good reason been touted as essential reading for military leaders but people from many other fields also benefit from his insights. It’s not an easy read but reader freindly adaptations of his book surface regularly with many of these have a focus on a perticular disciplines for example, executives, salespeople, and even golfers. To my knowledge it has not yet been adapted to IT. I often think about how this book relates to IT project management practices and methodologies.
The Art of War can be interpreted as a project management framework in the sense that it consists of guidelines, strategies and methods for dealing with various situations. He deals extensively and expertly with what we know as Risk Management in particular the ways of anticipating and mitigating various challenges. He dispenses sound advice about the virtues of winning wars without fighting battles. Sun Tzu also comments extensively on the characteristics of a good leader and standards for efficiency and effectiveness. Though written for a different audience and purpose I find that many of the principles he lays out can be adapted to help us manage our teams, our projects and the situations we face daily.
Sun Tzu encourages us to be flexible, to respect the uniqueness of each and every situation. We should not rely blindly on methodologies and frameworks not even on his guidelines. In the end decisions must be made by people rather than on behalf of people. Conversely he cautions that an absence of standards and methods will lead to chaos. Standards are for us to adapt and to blend with our experiences and most importantly to adapt to the task and circumstances at hand.
Having frameworks and methodologies should not be a substitute for creativity and innovation but rather should encourage and guide them.
March 5, 2007
Experience teaches me that the formula for a successful software system implementation has three critical elements: technology, process and people. Successful projects factor all three of equally important aspects of the technology-induced change.
As an IT consultant who manages the implementation of business systems I’m often exposed to communities of system users who experience change anxiety in their work environments. Even when warned of the impending changes, and with many of them actually contributing to the process, the change is often overwhelming to impacted users. If the situation is left unmanaged the cries for things to go back to the way they were can start long before the implementation. The impacts on the software project can be devastating. The impact on staff and morale can be worse.
So why does this happen ? The reasons are as diverse and the changes themselves and too dependent on local context to be captured in one model but some of the recurring themes are:
- Loss of control, lack of flexibility, loss of power.
- Fear of the unknown, forced learning, change in routine.
- Fear of looking “foolish”
- Loss of relevance of formerly valued knowledge
- Bad past experiences
As an IT project manager I have learnt that system adoption is a risk factor that must be accounted for and managed. Even if the there is no question that a change is required, it could (and often is) resisted. You know you have not managed change when the level of resistance far exceeds the magnitude of the change.
So how do we manage this change? In a word communicate. The trick is to know what to communicate, to whom, how and when.
February 27, 2007
What constitutes success of a project? The common answers I get to this question generally focus on the project deliverables and whether these are on time, to cost and to specification. But can a project be a true success if the planned business outcomes are not realized. Can we reliably trust that by producing the deliverables on time and on budget that business value will be generated ?
I try to expand the traditional view of project success to include the achievement of specific business outcomes. Delivering Benefits, to the sponsoring organization should be the sole purpose of any project. Every project starts out with good intentions and a plan to deliver what its sponsors think they need. But too often the benefits everyone expects are promptly laid aside when the project work begins. This focus is then replaced with a focus on producing deliverables on time and on budget. Even if they take the time to clearly define their goals, many companies stop short of testing their assumptions to determine whether the goals can realistically be achieved. Some teams become so obsessed with producing deliverables that they become blind to the fact that those deliverables may fail produce the intended benefit.
Benefits management requires planning and constant testing of the assumptions that create the benefits at each stage in a project’s life cycle, not just at the end. This allows managers and project teams to take corrective action or refine the expected benefits, based on interim results. A structured approach to defining and monitoring a project’s benefits ensures that the promises made in the business case actually do materialize.
Don’t get me wrong, I get that being on time and on budget is a good thing, but it’s not the only thing.
February 25, 2007
I’m working on a couple of presentations this weekend and thought I’d share a few thoughts about communicating. Most of these were learnt the hard way.
- Understand your audience. If it’s one executive, do everything you can to determine his or her “hot buttons”: Key motivators, personal and organizational goals, likes and dislikes. If it’s a small group, analyze the group the same way by keeping in mind the groups objectives and their relationship with their peers. Personalize your messages to your audiences preferences in any and every way you can.
- Focus on a few key messages. You may know all there is to know about the subject, and may be tempted to explain it all. Resist this temptation because you risk diluting your message. Choose no more than five key messages (fewer is better). If you can’t reduce your list, you need to pull back to a higher-level perspective.
- Marketing firms used to say that the consumer needed to hear the message 7 times for it to register. I don’t know if 7 is the right number for my type of work but I do try to find several ways to deliver my messages. I tell them what I am going to so, say it, demonstrate it, use humour, provide evidence and summarize it.
- Stay on Topic. Questions may lead you off topic. Resist that temptation. Remember your key messages and lead the conversation back to on topic. Don’t dilute your most important messages by wandering afield.
- Choose your medium carefully. Your key messages and your audience’s preferred communication styles should determine the medium. You can’t assume that someone will read your email and if the message is that important then you have to make sure it’s received and understood. If your audience is an executive who wants to look you in the eye, make sure you meet face-to-face. And even though you like to scribble on the whiteboard while talking you need to consider that your audience might reject your message because whiteboard-scrawling might from their perspective suggest lack of preparation. If it’s important for you that your audience hears you then you must tailor your delivery to suit their preferences.
- Use formatting to reinforce your message: When you communicate face-to-face, your vocal intonation and body language deliver as much information as your words. In email or reports, intonation and body language aren’t available to you. Formatting can be used to substitute for them. You know what your key messages are but how are you going to make sure the reader remembers them? The act of formatting helps you think things through. Deciding what to bold or italicize, what to put in a bulleted or numbered list, what to separate into a sidebar, how to use color, what to illustrate through a chart or graphic … or in PowerPoint, whether and how to animate a graphic or bulleted list, and what to put into a “kicker box” at the bottom … these decisions help you think through your message.
February 9, 2007
I’m learning many things concurrently these days. The game of Go, playing the guitar, Scrum, shooting pool, fly fishing, writing, etc. As I do this I’m also observing a pattern in the ways, pace and manner in which I learn.In some areas, like project management or golf, I feel that the knowledge I’ve already gained allows me to learn horizontally, in small chunks and at leisure. I feel like I am broadening and deepening my knowledge by making connections between things I already know. I’m not pursuing any one topic systematically but rather letting curiosity lead me to random explorations. This feels very comfortable to me and despite the fact that there are no specific goals I feel I continue to make progress.
Other newer disciplines like Go, Scrum and fly fishing bring me opportunities for “breakthroughs”. Before a breakthrough, the feeling is that my abilities are seriously limited – that I’m banging my head against some imaginary wall. From time to time I punch a small hole in that wall and learning becomes freer and takes on an incremental degree of that “comfortable” state. That’s when I know I’ve progressed a level. The breakthrough is exhilarating and re-energizes the learning, I think that most learning actually consists of practice. Along with repetition and exercises I also include research, study and experimenting. This is where I’m at on the guitar, on what looks to me to be a perpetual never ending plateau. So much so that I now like to say that I don’t play the guitar but rather that I play with the guitar. I play at least 15 minutes a day, mostly simple but recognizable pieces. I try to make it sound right and am absorbing a little theory as I go along but It feels like a steep slope and usually feels like making no progress at all. Practice without breakthrough can be discouraging. Fortunatly I’m having better luck with fly fishing, Scrum and Go.It’s interesting to be learning several things at the same time and to draw comparisons. I’m observing how these different types of learning; comfortable learning, breakthroughs and practice form cycles. I feel sure that before long, my Go playing will become practice. If by then I have not developed passion for the game, it may drop off the list to be replaced by the next thing. I have noticed how the “comfortable” states last until they become stale, at which point you start looking around for a breakthrough to take you to the next level. And so it goes.
February 8, 2007
Today I attended a customer presentation on their PMO and that got me thinking about how just a few years ago I was asked to establish something like it. I now find myself reflecting on that experience, the experience of my customer and on how ThinkWRAP approaches the problem.
There still does not seem to be any one universally agreed upon definition of what a Project Management Office is, and there likely won’t be one. PMO means different things to different people, and I now accept that that is how it should be. Differences in purpose, scope and orientation are both necessary and desirable. I observe however that acceptance and reliance on the PMO are obstacles we seem to have overcome.
PMOs are being established and senior project management positions are being staffed in recognition that project management is essential, and that businesses need these capabilities to be successful. Most organizations are still a long way from attaining the same level of maturity of their project management that they have of other disciplines like Finance or HR. It’s not yet quite there yet but it’s well on the way.
There is still work to do in terms of developing a mature and effective project management capability and I maintain that this is an important function of the PMO. For many organizations an investment in developing project management has been made but for these the focus must be placed on making sure that capability is permanently embedded. You can’t just build a process, publish it, provide some training and call it done. The discipline must become entrenched. Done right we will in time reach a point where the capability becomes embedded and executive support and reinforcement are no longer required. The real stumbling block is determining what accountability the PMO carries. Once that hurdle is crossed the rest falls into place rather nicely.
So what does this mean for the ThinkWRAP PMO? The focus of our PMO is in doing the work by providing hands-on support in the actual management and delivery of projects. For us this may take a number of forms. It might be coordinating the project planning, estimating, financial planning, risk assessment, project governance, initiation process, resource planning, and or actual project delivery. The development of approaches and the selection of technologies must be left to the project teams themselves but the PMO has a role to ensure that collaboration is encouraged, that previous learnings are applied and that re-usable componenents or knowledge is leveraged.
Our PMOs will address all of these dimensions. The focus may be on a specific client project portfolio, product management or enterprise projects within an organization. The measure of our PMO will be the bottom-line value that it contributes toward getting projects done.