Level: Introductory S. E Slack (sally@sslack.com), Author and business transformation communications consultant, Freelance writer
18 Sep 2007 As an architect, you aren't involved in day-to-day project management, but you can dramatically improve a project by analyzing and communicating your knowledge about risk factors, complexity, budget, and deadlines.
If you've been an architect for long, you've already seen what happens to your
design once approvals have been obtained. A deployment team grabs hold of your
design and moves forward to make the design become reality This can be an
exhilarating time for any architect—who doesn't love to see their designs
come to life?—but it can also be a bumpy road filled with roadblocks and unexpected curves. Even when a design seems perfect, there is no guarantee that its deployment will be. You can help those who manage the daily aspects of implementing your design by considering budget and scheduling concerns before deployment occurs. Minimizing overly complex design features and watching for risk factors that can impede a design's progress are other key factors to keep in mind when creating your design. This article looks at each of these items and provides tips that will let you help deployment teams bring your design to life.
Budget and scheduling blues
It's rare that information technology (IT) departments, deployment managers,
and architects hear the words, "Don't worry about the budget." I can't think of a single time I've heard that phrase on a project! Instead, most architectural designs are sent to deployment teams that promptly shred the design in order to determine which aspects are economically feasible and which must wait until a later date for implementation.
Deployment managers don't shred designs because they want to; they do it out
of necessity. The manager's task is to deploy the project on time and on budget, two items that are dictated by executives who have limited budgets and a desire to show that certain milestones have been achieved by specific dates. When an executive says X dollars are available and the project needs to be completed by X date, that's what they want. No executive wants to hear that a deployment is missing deadlines or can't be implemented for the budgeted amount. Both make the executive look bad to their peers and bosses, and that's never a good thing.
This situation gives a deployment manager limited options. Either they can go
to the executive and try to explain why a project won't deploy on time or why more money is needed or they can get pieces of the project deployed to make the executive happy and keep the project moving. Establishing a limited scope up front can help the deployment manager keep the executive realistic about what can or can't be achieved by certain dates and lets the deployment continue to unfold over time.
But this type of approach doesn't always bode well for the architect who is judged on the effectiveness of the design. If a deployment manager chooses to deploy a piece of the design that can't be used until another piece of the design is deployed, your terrific design suddenly doesn't look so effective. What can you do to help with budget and scheduling problems? I'll outline some ideas in the following sections.
Establish incremental scopes
You already know the deployment manager will have to do this, so why not do
it for them? That way, the design can be implemented in the manner you think
is most appropriate to achieve overall effectiveness. You're the one who knows
the design best; which pieces of it are most critical, and which ones can wait
for a third, fourth, or fifth deployment phase.
Thinking of your design in pieces as opposed to the whole product puts you in
charge as deployment occurs—you can make the recommendations to the executives and the deployment manager instead of fighting against potentially inaccurate decisions they might make on their own. This thought process also helps you to prioritize requirements and helps to facilitate development cycles—both of which are immensely helpful to the deployment manager.
As an added benefit, you can use the incremental scopes to create a shared vision with the executive and the deployment manager; among the three of you, you can create the right action plan for your design. This not only gets you in front of your executive again and shows them your dedication to ensuring the design works well for the organization, but also it establishes you as a key partner for the deployment manager.
Identify skills needed
Sure, the deployment manager pulls together the members of the deployment team. But who knows which skills and skill levels would be most beneficial to deployment of your design, if not you? Identifying the particular skills or skill levels needed for various aspects of deployment can help a deployment manager plan more accurately for resources, which in turn can save plenty of time during deployment.
Think of it this way: If you know it will take two senior systems engineers and one junior engineer to build and manage the storage area network (SAN) required for your design, why not share that information with the deployment manager? If you don't, they may not recognize the full impact of the time and skill levels required for that particular piece of the project—and the deployment may be slowed as a result. Never hold back information if you know that certain skills and experience levels will help a design deploy more effectively.
Get realistic about testing
Testing phases can suck up a lot of time during a project. If testers run into problems, the project can be set back by weeks or even months. Think ahead about the specific testing that will be needed to implement your design, and be ready to share that information with the deployment manager so the proper planning can be done to include the necessary time. For example, if you know integration among three systems will be critical to the design's success, what kind of testing should be done? Should scenarios be used? If so, who will build them, and how much time will they need? Or should sandboxes be used to test certain elements of the design before any other deployment activities begin? Will user testing be required at any point? Sharing this kind of information with a deployment manager can help them make decisions up front about scheduling issues; that way, the manager won't be caught off guard when they realize at a later date that scenarios need to be developed but no time was provided for doing so.
Use lessons learned from other deployments of your designs
Look back at previous deployments of your designs. Did you like how certain aspects were handled? Were you frustrated with others? The lessons you learn from every design and deployment can—and should—be used each time you work with a new design and deployment. For example, was a deployment delayed because of excessive testing required for your design? If so, be sure the current design has taken into account any problems that were identified in earlier designs.
Also take time to look at other designs that have deployed recently in your organization, whether successful or not. What went right—or wrong—with them? Can you find any lessons in the way those designs were created? Although it's tempting to think that your design is the best way to handle something, it's a good idea to keep your mind open to the ideas that other architects can offer you.
Document, document, document!
Few people realize how much time team members spend during a deployment attempting to understand the various aspects of the design. As the design's creator, you obviously know all the details and how they fit together. But people just coming into a project spend a fair amount of time getting up to speed on the applications involved and what those applications are expected to do.
For instance, I worked on one project as the worldwide communications lead. I was expected to know every detail of how the applications would impact users so that I could translate those technical details into basic communications for end users. As I asked about a particular application, it became clear to me that almost no one on the project understood the application or what it was supposed to accomplish once deployed. They just knew it needed to be deployed and assumed I would be able to figure out what it was and why it was needed. It took me weeks of phone calls, meetings, and begging to finally track down the information required. The moral of this story? Never assume that anyone besides you understands why certain things must occur in a deployment. Write down the information, and keep it easily accessible to everyone on the project.
Analyze complexity and risk factors
The level of complexity in enterprise and application architectural designs can't
be underestimated in today's world. Even though most larger corporations have dropped legacy systems in favor of distributed business applications that are less cumbersome to deploy and operate, dozens of underlying pieces (called building blocks) such as databases and servers can create nightmares in a design.
The more you can build a common strategy and IT language into your design, the easier it will be for deployment teams to implement. It doesn't take a rocket scientist to realize that a complex design is more expensive to operate; difficult to manage before, during, and after deployment; and unpredictable when changes must be made in the future.
Also think about the operational changes that will undoubtedly be made over time
(fixes, security patches, hardware updates, and so on), and take some time to carefully analyze the environment for your design. For example, if you're designing for the sales division, what's the history of change? Does that group have a tendency to accept IT changes, or does it routinely fight back against even routine updates?
Risk factors in a design can come in all shapes and sizes, but the most important
are those that will stop the design from becoming the effective solution you know
it can be. Although risks differ between organizations, many can be avoided by
using a structured framework and process management system. For instance, the
IBM® WebSphere® product line includes several different products that can help you design rules and integrate them into business processes (WebSphere Integration Developer) or start with prebuilt frameworks to speed the delivery and assembly of business services (WebSphere Business Services Fabric).
Knowing ahead of time what can put a deployment at risk will help any deployment
manager. Imagine the surprise, for instance, when the architects of one project I
worked on discovered that parts of Asia's broadband system couldn't support the
primary application being deployed. It took weeks to prepare the solution, which
brought the project to a screeching halt for that period of time.
Analyzing the complexity and risk factors isn't just for your benefit, it's for
the benefit of the entire deployment team. If you know that the sales team has a
tendency to push back on every change, come up with a plan that can help the
deployment manager win the battles that must be fought. Help the deployment
manager understand the pieces of the design that are "nice to have" as opposed to
"must haves" so they can concede certain points when needed and move on with
deployment. If your deployment manager has never worked with the sales team and you have, you can be an immense asset and save plenty of valuable time from being sucked away by unnecessary arguments.
Summary
You may not be responsible for the day-to-day management of a project, but
you are responsible for the effectiveness of the final design that is
deployed. Savvy architects have a clear understanding of the issues and
requirements related to a project's budget and schedule, and they work
proactively with deployment managers to help projects run more smoothly. You
won't get any glory for being the behind-the-scenes project manager, but
you'll have the satisfaction of knowing that you've done everything you can
to make your original vision come to life in the best possible form and in
the fastest time frame possible.
Resources Learn
Get products and technologies
Discuss
About the author  | 
| | S. E. Slack is a freelance writer and author with more than 16 years of experience in
business writing. She has also been an executive and business transformation
communications consultant to IBM, Lenovo International, and State Farm Insurance Companies. She is currently writing CNET Do-It-Yourself Digital Home Office Projects: 24 Cool
Things You Didn't Know You Could Do (McGraw-Hill) and is the author of six
other books. Contact S.E. Slack at sally@sslack.com. |
Rate this page
| 
